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Abstract 



Problems inherent in representation and manipulation 
of large data-bases are discussed. Data management is 
considered as the manipulation of relationships among 
elements of a data-base. A detailed analogy introduces 
concepts embodied in a data management system. Set theory 
is used to describe a model for data-bases, and operations 
suitable for manipulation of relations are defined. The 
architecture chosen for an implementation of the model is 
illustrated, and a representation of data-bases is suggested. 
A particular implementation, the GOLD STAR system, is inves- 
tigated and evaluated. The framework outlined is meant to 
provide an environment in which complex data handling prob- 
lems can be solved with relative ease. GOLD STAR provides 
the user with tools sufficient for manipulation of arbi- 
trarily complex data-bases; these provisions are presented 
in the form of an extremely simple interface. 
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CHAPTER I 
INTRODUCTION 

The M.I.T. Electrical Engineering Department, like 
other large organizations, requires a powerful data manage- 
ment capability to provide information for daily operation. 
The department currently utilizes a software system developed 
by Burton J. Smith'- 1 " 1 -' which operates on the M.I.T. Compatible 
Time-Sharing System. Faced with the burden of manual gener- 
ation of teaching and research assignments, budget reports, 
mailing labels, and other documents, the department began 
in 1966 to transfer these tasks to the CTSS system with a 
significant saving in production time, personnel effort, 
and cost. With the forthcoming demise of the 7094 CTSS 
installation, an alternative computer system is needed, 
and provides the motivation for this thesis. 

For any integrated information system, the flexibility, 
and hence the scope of its utility, depends heavily upon the 
sophistication of its associated data management system . 
While this term connotes the existence of various functions 
to different individuals, the prime purpose of such an 
entity is to provide a coherent and systematic method of 
manipulating large volumes of interrelated data. Such a 
purpose is laudable, but only if a user can avail himself 
of the capability in a manner which makes the results, as 
well as the process, meaningful to him. 



Our concern in this thesis is the development of a data 
management facility capable of serving a wide variety of 
administrative information needs. Specifically the system 
characteristics are: 

1. Pre-eminence of User Perspectives and Techniques. 
A data management system is most effective when a 
user can express his problem to the system in terms 

of his perspective and biases; to the faculty planner, 
data types such as "name", "salary", and "project" 
hold much more meaning than representation types like 
INTEGER, DECIMAL, or BIT. For the same user, the 
operation "SORT (PHONE_BOOK, (TEL, NAME, ADDR) ) " 
expresses his purpose more than the effort required 
to write his own sorting routine. A good data man- 
agement system will minimize the degree to which a 
user alters his perception of, and approach to, his 
information problems. 

2. Modular Construction. 

While extensive planning of a system is advisable 
before development, experience indicates that soft- 
ware systems evolve with time rather than merely 
exist. That is, pre-planning a system rarely 
encompasses all features that may be desired at 
some unknown point in the future. A system should 
be modular in the sense that features added or 
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deleted in the evolution process disturb only local 
portions of the system. Modularity obviates the 
need for redesign and re -programming at each change. 

3. Expottability 

An organization may change the computer system it 
utilizes for data processing, but such a change 
should not disrupt the operation of the firm or 
division. While few computer programs are machine 
independent , a data management system can attain a 
high degree of exportability or relative machine 
independence, by isolating particular machine depen- 
dent features in a few modules. The remaining 
system modules should be written using a widely 
available higher level language. Design of a data 
management system with this objective in mind mini- 
mizes the operational disruption occasioned by a 
change in the target computer. 

The goals outlined thus far apply to design philosophy ; 
as such they pertain to all features which a data management 
system may exhibit. There are, however, more specific 
requirements placed upon any particular data management 
system, requirements dictated by the characteristic environ- 
ment in which the system must operate. The envisioned 

,[1-2] 
system is best suited to a "computer utility" environment, 

and as such requires two further considerations: 
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4. Controlled Sharing Among Users 

A computer utility provides the services of computa- 
tion for a broad-based community of users. Since 
some information, such as salaries and grades, is 
often considered personally sensitive, it is of 
prime importance that only those members of the 
community who require this information be allowed 
access to it. The strategy of allowing a user to 
access only these relations he creates would largely 
protect the integrity of sensitive information. 
However, such an extreme requirement eliminates 
effective communication among users whose data 
purviews overlap. 

5. On-Line Capabilities 

Management of a department or office occasionally 
requires instantaneous access to the data-base. 
The ability to update files from a remote terminal 
is extremely convenient; data may be entered by a 
secretary as if she were typing a report, obviating 
the need for keypunching and physical handling of 
cards. However, the greatest need for on-line 
access arises when a user searches the data-base for 
specific facts, and based upon the computer's re- 
sponse, asks for any of a wide range of additional 
data. For example, the university bursar may ask 
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for student accounts showing a lapse of payment 
greater than 30 days, along with the total number 
of dollars receivable from students. If the total 
due were mostly a result of the overdue accounts, 
he could generate address labels for those students 
tardy in payment and send notices using these labels, 
Interaction of a user with his data-base in this 
fashion is a powerful administrative tool, and thus, 
a justification for on-line capabilities. 

The concurrent requirements of sharing and pre-eminence 
of user perceptions of relatedness present the sub-system 
designer with a formidable task. Vendors of software pack- 
ages offer a variety of solutions but almost all efforts 
focus on representation and manipulation of data elements. 
GOLD STAR (Generalized Organization of Large Data-bases; a 
Set Theoretic Approach to Relations) , however, focuses upon 
the representation and manipulation of relations among data 
elements. This focus should be the prime function of any 
data management system. The functions of the GOLD STAR data 
management system are: 1) to implement an arbitrary concep- 
tualization of relatedness among entries in a data base, 
and 2) to transform the specified operations on the data 
base into sequences of instructions which will produce the 
effect of these operations. Thus the design intention of 
GOLD STAR is to remove, as far as possible, computer con- 
straints on the conceptualization of a data management 
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problem, while providing a direct means of mechanizing the 
same . 

Several methods of implementing such a system are possi- 
ble; in the first effort, GOLD STAR is imbedded within the 
PL/1 language as a set of function sub-programs. Imbedding 
allows the user full access to GOLD STAR without the burden 
of mastering some esoteric programming language; rather it 
extends the power of an established programming system to 
the realm of relation management. Imbedding permits imple- 
mentation of a model at low cost; the model's utility and 
power can be evaluated, as well as operated, without devel- 
opment of a special purpose compiler or interpreter. GOLD 
STAR assumes that calls to the imbedded functions are 
"primitives", i.e., a user need endure no greater complexity 
than these calls. GOLD STAR is written entirely in the PL/1 
programming language and its facilities are available to any 
program written in PL/1. 
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CHAPTER II 
THE STRUCTURE OF GOLD STAR 

To explain the data-management system developed in this 
thesis, we shall use an example designed to illustrate and 
motivate the system structure we have chosen. By introducing 
additional concepts to the analogy, it will be possible to 
explain all of the major issues of the GOLD STAR system. 
Following the example, we will relate the user's needs to 
the data-management system by both describing the general 
kinds of operations he might wish to perform, and the way 
in which the system conforms to the goals outlined in the 
first chapter. 

We assume that a small company has decided that it 
should establish a name- address -telephone number directory 
of its employees, although it has only eight employees. 
The preliminary, hand-written draft of the directory appears 
in Figure 2-lon the next page. 

This preliminary draft of the directory has some very 
important properties which should be noted. First, each 
line not only contains three items of information (i.e., a 
name, an address, and a telephone number') , but it states by 
its physical structure that each of these items is in a 
sense related, i.e., they "belong" to each other. Second, 
each item in the directory is associated, by its column, 
with a heading or type . Hence, "541-6622" (a telephone 
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Name 

Abernathy, Fred 
Barnes , John 
Donnelly, Bill 
Jones , Art 
Jones , Sally 
Manning, Pete 
Manning, Pete 
Parker, Irv 
Sanders , Doug 



Address Telephone 

22 Maple Street 783-3055 
13011 S. Weymouth Drive 249-8112 

2 Wallingham Place 247-7731 
53 Main Street 724-3718 
53 Main Street 724-3718 
264 Carling Avenue 861-8366 
264 Carling Avenue 861-4431 
10 S. Pannert 541-6622 

3 Mangrove Plaza 443-8190 



Figure 2-1: Preliminary Draft of Directory 
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number) would never be found in the same column as "Parker, 
Irv" (a name). Third, the directory itself is characterized 
by the types it contains (in this case name-address- tele- 
phone) . Finally, we note that the first column is in alpha- 
betical order. This makes a line easy to find when given a 
name . Hence, "Jones, Sally" is much easier to locate than 
is "861-8366", since the directory is ordered primarily by 
names rather than by telephone numbers. The left- to-right 
representation of the directory is usually used to imply 
that the further left we look, the more order a column pos- 
sesses. This is a convention adopted in most cases which 
is not innately necessary. 

Now let us complicate the problem -- a printing strike 
is in progress when the directory is to be published. Print- 
ing costs are very high, with charges figured on a per charac- 
ter basis. In assessing the alternatives, management real- 
izes that the company currently possesses a microfilm storage 
system for which each employee has a small console unit. 
These consoles each have an array of push-buttons which are 
used to display selected information on a screen. 

Management decides upon the following approach to make 
the directory available to the employees: the names, ad- 
dresses, and telephone numbers are placed on microfilm, and 
a list of which button is to be pressed on the consoles to 
retrieve information about which employee is readied for 
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printing. Thus, if you were to press the button "name" 
(this loads the "name" cartridge ) , and then the button "1", 
"Abernathy, Fred" would appear on the screen. In Figure 2-2 
we picture the information stored on microfilm as well as 
that printed. 

At this point the use of this directory is not neces- 
sarily clear. However, before considering how, we should 
observe a number of important concepts embodied by this 
change, and which motivate the change. 

1. The headings in the printed directory (Figure 2-2-d) 
are still necessary in order to know which car- 
tridge to load when information is requested. 

Thus an item of information is associated with 
both a button number and a (cartridge) type. 

2. The only association between these cartridges 
and this directory are through the headers (and 
corresponding cartridge types) . The same "name" 
cartridge would be used as part of this company's 
name- department listing . Note that a saving is 
reaped for this second listing in that a new 
"name" cartridge would be unnecessary. 

5. Although one forms a mental picture of the 

contents of a cartridge such as is illustrated 
in the figure, we do not actually know how the 
information is physically stored. The extent 
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Cartridge No. 1: Loaded by pressing "name' 



Sutton No. For Retrieval 
1 
2 
3 
4 
5 
6 
7 



Information Retrieved 
Abernathy, Fred 
Barnes , John 
Donnelly, Bill 
Jones , Art 
Jones, Sally 
Manning, Pete 
Parker, Irv 
Sanders, Doug 



Figure 2-2-a: Name Console Cartridge 



Cartridge No. 2: Loaded by pressing "address" 



Button No. For Retrieval 
1 

2 
3 
4 
5 
6 
7 



Information Retrieved 
22 Maple Street 
13011 S. Weymouth Dr. 

2 Wallingham Place 
53 Main Street 

264 Carling Avenue 
10 S. Pannert 

3 Mangrove Plaza 



Figure 2-2-b: Address Console Cartridge 
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Cartridge No. 3: Loaded by pressing "telephone number" 

Button No. For Retrieval Information Retrieved 

1 783-3055 

2 249-8112 

3 247-7731 

4 724-3718 

5 861-8366 

6 861-4431 

7 541-6622 

8 443-8190 

Figure 2-2-c: Telephone Console Cartridge 

The Printed Directory 

Name Address Telephone Number 

1 1 1 

2 2 2 

3 3 3 

4 4 4 

5 4 4 

6 5 5 

6 5 6 

7 6 7 

8 7 8 

Figure 2-2-d: Printed Directory 
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o£ our knowledge is that we can perforin two func- 
tions: we can press a numbered button (presumably 
we have already loaded the cartridge) and have the 
corresponding data item appear on our screen, or 
we can somehow type in a data item (the hardware 
is irrelevant) and have its button number appear 
on the screen. There is no reason to believe 
that names and addresses are stored in the same 
physical manner in the cartridges, despite the 
fact that the console performs identically for 
all corresponding requests. 

4. Some tasks become easier. In glancing over the 
directory, "Jones, Sally" will be more easily 
mistaken for "Jones, Art" than "5" will be for 
"4". In addition, comparisons are easier by 
mere virtue of the fact that directory entries 
are now a single number rather than a multi- 
character name (or address, etc.). 

5. There is an implied order on button numbers 
(numeric, of course). Hence, in the case of 
"name" numeric order on the button corresponds 
to the alphabetic order on the names. However, 
in the case of "address", where no order was 
assumed in the beginning, the task of deter- 
mining the button number associated with a 
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given data item is a hard one -- all address 
entries must be checked (i.e., there is no 
guarantee of any relative positioning for the 
addresses) . 

6. In cases where duplication of items occurs, 
large savings accrue from the given organi- 
zation. For example, although Pete Manning 
has two lines in the directory, all that must 
be printed twice is his button number. His 
name is stored only once on the "name" cartridge. 

7. The directory is meaningless out of context 
(i.e., with no headers). One would not know 
which cartridge to load before pressing the 
buttons for inquiry. 

In order to consider how the system is used, we take a 
name and request the associated address and telephone number. 
First, the "name" button is pressed to load that cartridge. 
Then the desired name is inserted and the associated button 
number is read off the screen. Now we look in the printed 
directory for the line with that number in the name column 
and retrieve the other information by pressing the appropriate 
cartridge load button and number button. 

Note that we have said that the printed directory in 
this numeric form retains exactly the same properties as did 
the original listing with the complete text (Figure 2-1). 
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There are new considerations (as outlined above) , but there 
are no conceptual differences in the information content of 
the two methods of representation. 

Let us now assume that negotiations in the printer's 
dispute have broken down altogether; now no printing services 
are available. Management can either wait for the printer's 
strike to end or seek an alternative. They decide on the 
following alternative: a new set of microfilm equipment is 
purchased, with each employee receiving a terminal (we shall 
distinguish these "terminals" from the previously discussed 
"consoles"). This new system (the terminal system ) is to be 
employed to store the directory itself in a directory- car- 
tridge , which will be named, appropriately, "name- address- 
telephone number". The facilities of the terminals must be 
more complex than the consoles in order to handle these more 
complex directory-cartridges. 

The terminals are capable of responding to requests such 
as " display the line in name- address- telephone number con- 
taining "5" in the address column." The request itself is not 
necessarily in English, but the key words corresponding to 
load directory (first "in"), locate line ("display"), look in 
a given column (second "in"), look in a given column for a 
given button number ("containing") correspond to buttons. In 
addition, the terminals are equipped with the ability to read 
and create magnetically inked listings of the directory car- 
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tridges. These listings are used to verify the entire con- 
tents of a directory cartridge, or to insert a new cartridge, 
or to make modifications, or other such operations. Note 
that the listings produced and read are in exactly the same 
format as the one in Figure 2-2-d. 

Now, again, we focus on some key considerations gener- 
ated by the change in our information storage arrangement. 

1. We still have no idea how a directory is physically 
stored on a directory- cartridge. We know only 
that the terminal can perform various tasks 
(which we will elaborate on later) on the 
directory-cartridges such as load them, inquire 

of them, and make a listing from them. The data 
items stored in these directory cartridges are 
the same button numbers which would have appeared 
in a printed directory (Figure 2-2-d) and are to be 
used on the consoles to obtain text from the 
screen. Further, there is no reason to assume 
that all directory cartridges have the same 
physical format. 

2. The logical structure used in different directory 
cartridges may be different. The "relatedness" 
implied by the line structure may be recorded 

in ways other than lines. The only requirement 
to be met by the other logical structures is 
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that they be capable of being translated into 
a listing of the form of Figure 2-2-d. For example, 
Pete Manning's two different telephone numbers 
may both be associated with his name and address 
in such a way that the name and address columns 
need be physically present only once for his 
name . 

3. More than one directory-cartridge can be used 
in the terminal system. One such cartridge 
has no relationship to another. It is possible 
to have both "name-address- telephone number" 
and "name-department" cartridges, but the exis- 
tence of a given name in one says nothing about 
the existence of that name in the other (i.e., 
because a name possesses an address and number, 
we can determine no association between this 
name and any department) . 
Now consider the kind of operations we might want to 
perform upon the directory- cartridge (s) . If another company 
merged with this one and it used the same information system, 
we might want to merge the two "name- address -telephone number" 
directory cartridges to form one. Or, if an employee left, 
wc might wish to remove all lines about him from a directory- 
cartridge. Or, we might wish to "combine" the "name-address- 
telephone number" with "name-department" to give a new "name- 
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dcpartmcnt-addrcss-telephone number" directory- cartridge . 
These arc but a few of possible operations which we might 
want to perform. 

It would be premature at this time to discuss the full 
spectrum of operations we may wish to perform on the termi- 
nals and consoles. Rather, we extend our terminology by 
putting forth a general system structure for GOLD STAR and 
showing how the various components of the system correspond 
to our example. Then we may attempt to define at least the 
classes of operations we might do with the consoles and the 
terminals. The diagram of Figure 2-3, although it may seem 
cryptic at first, serves to characterize the GOLD STAR data 
management system. 

Now let us take the various blocks of the figure and 
discuss their function by referring to the example of the 
microfilm system. 

DSM (Data Strategy Module) : These correspond to the 
consoles and serve to translate between the refer- 
ence numbers (the button numbers) and the data items. 

DA (Data Area) : These correspond to the data cartridges 
which are part of the console system. Just as a but- 
ton must be pressed to load a cartridge, so must 
information be given to the DSM to tell it which DA 
to refer to when retrieving text or reference num- 
bers (refnos) . This "load button" is what is 
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referred to as a data - type name . 

RSM (Relational Strategy Module) : These correspond to 
the terminals and serve to perform operations on 
relational data just as the terminals perform oper- 
ations upon the directory-cartridges. 

RD (Relational Data) : These are the directory-car- 
tridges of GOLD STAR. Just as the directory- car- 
tridge must be requested by name, so must an RD be 
requested via a relation name (or rel-name) . 

QUART (QUAsi RelaTion) : These are the listings of the 
terminals. All RSM's can produce quarts or can, in 
fact, convert the contents of an RD t_o a quart. 
These are the fundamental units of the system in 
that all modules of the system can deal in some way 
with quarts. 

MGR (Manager) : There is no direct analogy to the mana- 
ger in the microfilm system. The manager is merely 
the module which has the effect of making button- 
pressing operations easier. It provides an easy 
language for the user to use in utilizing the avail- 
able powers of the DSM's and RSM's. 

CENT 4 PENT: Two representations (character and 

pointer) of a header . The rest of the components 
serve much more specific tasks and will be discussed 
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in later sections. To briefly review the main con- 
cepts again, information text is stored only once 
and a token refno assigned to it. The information 
of how data items are related to one another is 
stored separately and is operated upon separately. 
This approach allows the savings and features men- 
tioned in the discussion of the example to be 
capitalized upon. 
Consider briefly the classes of operations which will 
be desired from our components. 

{Data-String} -»- {refno} 
DSM 

(2-1) 

This is the translation of text into its reference 
number (refno) . We have assumed that the nature of 
the data string is known so that we can determine 
into which data area we must inquire. We have also 
assumed that each data area has one and only one 
DSM which can perform the indicated translations 
and that we can easily determine which DSM by 
looking in the data area. 

{refno} -»- {Data-String} 
DSM 

(2-2) 

This is the reverse of (2-1). The same assumptions 
hold true. It is worthwhile to note at this point 



-28- 
that each reference number is stored as part of a 
quart; these quarts also contain information indi- 
cating the data area to which this refno refers. 
Thus, the specification of data area can be either 
implicit (found from the refno' s quart) or explicit 

{refno} -> {refno} 
DSM 

(2-3) 

This is the way of representing a transformation 
through a DSM, such as "get the next refno after 
the one I supply". Again, the same assumptions 
as above hold, and data area can be implicity or 
explicitly indicated. 

{refno} ->- {refno} 
RSM 

(2-4) 

This indicates a transformation performed when 
information (in the form of refnos) is given to 
an RSM; what is returned is another bundle of 
information which has been found using the pro- 
perties of relatedness stored in a relation 
(relational data area). The appropriate RD and 
RSM are implicitly determined from a group of 
input refno quarts. 

{refno} -> R 
RSM 

(2-5) 
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This is the same as (2-4) except that the result 
is a complete RD containing the properties of the 
transformed refno input. 

R -+ {refno} 
RSM 

(2-6) 

This is the reverse of (2-5). 

R + R 
RSM (2-7) 

This is the transformation of one RD to another. 
A merge is an example of such an operation. 

These are the general classes of operations available 
to the user. The first three are those which would be per- 
formed on the console in the example. The final four would 
be performed on a terminal where {refno} would be a listing 
and R would be a directory - cartridge . These operation 
classes are quite general, and later sections will narrow 
their scope to certain well defined procedures. 

But now, how can we justify this rather complex struc- 
turing of the system in terms of our goals? Let us consider 
the goals one by one: 

1. User Perspective 

The concept of data-types, or headers, identify 
each reference number as being associated with a 
given type of data. Hence, the user thinks of 
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his data in terms of their type, or header, 
rather than in terms of its PL/1 representation. 
This is exemplified by the fact that no matter 
how data is stored on a console cartridge, the 
user can handle it merely by pressing the button 
corresponding to the cartridge name; i.e., the 
machine handles representational considerations, 
and the user is free to imagine all his different 
kinds of data in terms of their type name. 

2. Modularity 

The freedom to use virtually any organization of 
data or relations is guaranteed by this structure. 
All that is needed is an appropriate DSM or RSM 
to handle that format. The interfaces in the 
system are uniform and well defined; addition of 
new modules becomes little more than writing them. 
This fact is not easily accounted for in our model; 
we are proposing that new consoles and terminals 
are easy to add when new format cartridges are to 
be handled. 

3. Exportabil ity 

Of course, the major feature of the system for 
exportability is the PL/1 language (see Chapter I). 
Beyond that, two important facts remain. First, 
the manager can be designed to incorporate all of 
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the machine dependent code, leaving the RSM's, 
DSM's and information free for transplantation 
to any machine. Second, the interfaces are so 
explicit that any additional modules needed by 
a new machine could easily be interposed in a 
calling sequence between two system modules. 
There is no analogy to the example, except if 
the entire system were adopted by another company 
with different microfilm equipment. 

4. Controlled Sharing 

Clearly this system allows for sharing by mere 
sharing of data areas (cartridges). The control 
arises from the fact that access to relations can 
be given selectively. For example, an employee 
might have access to both the name and salary 
cartridge (Data Areas) but by being denied access 
to the name-salary relation cartridge (relational 
data) he has no way of making the associations. 
The advantage to this scheme is that the employee 
could well be permitted to examine other relations 
containing name and salary (e.g. name-address or 
salary- contract ) and still never be able to asso- 
ciate the two. On the other hand, circumstances 
might dictate that a console cartridge (or data 
area) be denied a user, and still allow to him 
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all relations involving it. For example, we 
might not care if it is known from name-classi- 
fication that ten people are of the same rank, 
but we might want to protect just what that 
rank is_. In short, with all data and relational 
data stored in modular units, we need worry in 
general only about sharing these units, rather 
than about sharing parts of a larger combined 
medium. 

5. On-Line Capabilities 

This is a function of how the system's functions 
are adapted for use, and does not bear on the 
system design itself. 

As to the unstated goal of efficiency, there are a couple 
of points to consider. Appropriate design of RSM's and DSM's 
can optimize operation to conform to the most frequent func- 
tion that the module must perform. For example, an RSM can 
be designed to optimize inversion, just as one can be de- 
signed to optimize retrieval operations of a uni-directional 
nature (i.e., with name- address -telephone , we are always 
given a name and asked for the other two, but rarely in any 
other order). Also, we achieve some saving of space by 
using reference number tokens in relations; duplication costs 
only the length of a refno, not of the data itself. 

That summarizes the structures and motivations of the 
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GOLD STAR system. In the next chapter, we will consider the 
set theory upon which these structures are founded, and h 
set theory leads in logical progression to the concept of 
quart . 

Chapter IV will discuss the implementation of GOLD STAR 
and provide an insight into some of its current design capa- 
bilities. Chapter V will present the user interface, i.e., 
the functional calls to the manager of the system. That 
section also discusses the programming considerations of 
note, as well as presenting an example of the use of GOLD 
STAR. 
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CHAPTER III 
SET THEORY OF GOLD STAR 

1. The Rhetoric of Sets 

Each individual perceives the "relatedness" of two 
items of data based upon his particular perceptions and 
biases. Visual proximity, concurrent sensations of taste 
and smell, or remembered patterns of association are but a 
few means by which the human mind establishes relatedness 
of two items of information. Different individuals often 
interpret the same collection of information in vastly 
different terms of relatedness; the string "V-8" as con- 
strued by the auto enthusiast signifies something afar from 
the meaning assumed by the connoisseur of vegetable juices. 

At the core of GOLD STAR rests the firm belief that 
data relatedness is best conceptualized apart from the com- 
putational processes which implement relatedness. One con- 
ceptualization method, set theory, permits this separation, 
and offers several unexpected benefits: 

-- Set theory is sufficiently general to encompass 
the operations and associations normally subsumed 
in the term "data management". 
--As an outgrowth of pure mathematics, set theory 
offers unambiguous, albeit complex, semantics; 
furthermore, set operations and their limitations 
are well established. 
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-- The subdivision of a system into independent 
functional modules is facilitated by a set- 
theoretic framework. Set- theoretic operations 
specify quite well the tasks that any single 
system module must perform. 
The remainder of this section discusses data-bases and 
operations upon them in terms of basic set theory. The 
following section treats data-bases in light of orderings 
upon their members. 
Data-Bases 

The notations and intuitive notions used in this sec- 
tion conform with common usagel ■■ As an abstract model of 
reality, a data-base depends upon certain concepts involving 
sets, most importantly: 

The set {a,b} is a collection of the objects "a" 
and "b" with neither ordering nor structure 
presumed among them. The elements "a" and "b" 
may be either atomic, i.e. not sets, or they 
may themselves name sets. Thus an element of 
a set can be another set. 
The ordered pair <a,b> is the set { {a} , {a ,b } } , and 
indicates in the following directed graph that 
the correct sequence of endpoints is "a" followed 
by "b". 

a »-b <a,b> 
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Thc tuple (a,b) is the set 1 <1 , a> , < 2 ,b> } , that is 
a function from {1,2} to {a,b}. Likewise, the 
tuple (n , ,n ? ,n„ , . . . .n, ) is a function from the 
set { 1 , 2,3,4, ... i-l,i} to {n 1 ,n 2 , . . .n i } . 
We define a data- base B as a tuple of order three: 

B=(D,T,R) (3-1) 

The set D contains data element names , and contains 
within its power set three particularly useful sets. 
D=N D UN 0N R (3-2) 

The members of N„ are raw data elements , that is 
elements apart from their relation to other elements. 
For example, the elements "John", "red", "3.5", and 



li'^ " could all be members of N„. 
The members of N ]V and particularly associations 
among its members, are the motivation for the struc- 
ture of the data-base B. Of first concern in this 
structure is the function T, the data type function 
T takes as its domain a set of data type names , N' T , 
N S D, and maps it into various subsets of D. More 



rioorouslv: 



(3-3) 



T=N T -P(D) 
From the example of Chapter II, 

N ={"namc" /'address" /'telephone") 



T(name) = {"Abernathy , Fred" , "Barnes , John", etc.) 
T(address)={"22 Maple St. ","53 Main St.", etc.) 
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T (telephone) = {"783- 30 55", "724- 371 8", etc.} 
T(data types)={"name", "address", "telephone" }=N T 

The last line is significant in that T (N T ) = 
T(data types) = N T . Note that this does not violate the 
axiom of regularity (x a set -+ x £ x) . N T is merely its 
own image under the function T; hence N T e dom T and 
N e ran T, but N T £ N T . 

T is a function, but since D is finite, the range of 
T cannot be the entirety of £>(D) , i.e. T is not an onto 
function. Furthermore, T is generally not one-to-one. Apart 
from constraints of cardinality, the first condition will 
usually hold because not all members of G\v) form coherent 
data types in the eyes of the user. The lack of a one-to-one 
condition results whenever two data type names (or more) 
have the same image under T. For example, the set 
S = {Babe Ruth, Bill Dickey, Tony Lazerri, 

Lou Gehrig} 
might be T(Murder's Row) or T(01d Yankee Sluggers). Note, 
however, that Ttname^ = T(name 2 ) does not imply that 
name, = name.,, as in the above example. 

The final element of structure within B is the mapping 
from N n , a set of relation names and the set of relations 
existing among members of Np. Before examining the formal 
definition of this mapping, we define the cartesian product 
(or cross product) over various members of the function T. 



Let I £ N T , then the cartesian product of T over I is 
defined as 

X T(i)={f |f :I+D § (Vi)(iel+f(i) e T(i))} 
iel (3-4) 

Thus the cartesian product is a set of functions , each of 

which is a set of ordered pairs; the following example 

illustrates : 

I={age , hair , eyes } s N„ 

T(age)={10,20} 

T (hair) = {brown, blond} 

T (eyes ) = {blue , hazel} 

X T(i)={{<age,10> ,<hair ,brown> , <eyes ,blue>} , 
iel 

{<age ,10> ,<hair,brown> , <eyes , hazel >} , 

{<age , 10> ,<hair,blond>,<eyes ,blue>} , 

{<age , 10> ,<hair,blond>, <eyes , hazel >} , 

{<age, 20> , <hair ,brown> , <eyes ,blue>} , 

{<age, 2 0> , <hair , brown > ,<eyes , hazel >} , 

{<age , 2 0> ,<hair ,blond> ,<eyes ,blue>} , 

{<age , 2 0> ,<hair,blond>, <eyes , hazel >} } 

If |S| denotes the number of elements in the set S, then 



X T(i) 
iel 



= n |T(i) 
iel 



A relation is defined as a subset of some cartesian 
product of T over a subset of N„. The function R maps N R 
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into the set of all possible relations among members of the 
data-base. Rigorously, 

T (3-5) 

Specifically, if xeN R , and R(x) is a relation over the 
cross product of T over some set I, I s N^,, 

R(x)s X T(i) 

iel (3-6) 

Note that the set I may have several relations associated 

with the cross product in (3-6). For example, several 

different relations could be drawn from 

XT(i) 
ie{name , address , telephone} 

yet all would be subsets of the same cartesian product. 
This implies that the exact contents of any relation cannot 
be established from knowledge only of the data type names 
involved. 

The model B defined constitutes one of many possible 
models. However, the choice of any one model depends upon 
how well it represents reality, and more importantly, how 
well its behavior can be made to conform to the behavior of 
the situation it represents. From our data base, we wish 
to selectively retrieve certain pieces of information; hence, 
wc require a set of operations which allow maximum control 
over model behavior. In addition to the cartesian product 
operation in (3-4) five other operations on members of R 
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will prove useful. 

Let x,y e N R and 



R(x) s X T(i) I = dom R(x) I -N 
iel 

R(y) S XT(j) J=doin R(y) J <= N 
j e J 



T 



T 



Note that I=domUR(x) and J=dom(jR(y) are the data type names 
which participate in R(x) and R(y) respectively. The oper- 
ations 

R(x) (J R(y) union 

R(x) f] R(y) intersection (3-7) 

R(x) - R(y) set theoretic difference 

are all defined if and only if I=J. Just as it makes no 
sense to add chickens to apples, the value of unioning a 
phone-book and a cook-book is moot within B. As with car- 
tesian product, union and intersection are commutative and 
associative; set theoretic difference is neither. 

Given a relation R (phone-book) 

X T(i) 
R(phone-book) eislname, address .telephone} 

we may wish to retrieve only a portion of the stored infor- 
mation. To isolate a particular set S of name-address-phone 
elements, we need specify only those elements of R also in 
S. However, if we wish to restrict a relation via data 
types, we define a projection on R(x) . Let X=dom(JR(x) and 
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let Y ^N T be the projection set . Then n y R(x) is the pro- 
jection of R(x) on those data types contained in XflY. 
Formally, 

TT v R(x) = {f:XnY-»-N | C3g)(geR(x) S fsg) } 

For example ^ {name , telephone } R ^ hone b °° k) W ° Uld yield * 
relation containing all names with associated phone numbers; 

each name-phone number pair in the projection is a subset 
of at least one name-address-telephone number tuple in 
R(phone book). If | domain U R(x) | =n, then there are 2 
distinct projections. Thus for R(phone book), the projec- 
tion sets {>, {name}, {name , address } , {name, telephone } , 
{name, address , telephone}, {telephone}, {address}, and 
{address, telephone} yield 2 3 =8 possible projections. Since 
f operates only on XAY , members of Y not contained in X 
have no effect on the projection process. Thus while a 
subset operation on R(x) yields a particular set of func- 
tions on domUR(x), the projection operation takes from all 
functions in R(x) those ordered pairs whose left component 
is contained in the projection set Y. 

Our sixth and final set-theoretic operation, that of 
relation composition, is the most powerful and the most 
difficult to define. Composition in GOLD STAR has two sim- 
ilar forms: composition in its simple form and composition 
under the auspices of a data type renaming transformation. 
Assume the existence of two relations- -a phone-book relation 
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and a name-salary relation; from these we wish to assemble 
a third relation indicating salaries at various addresses. 
Our algorithm follows : 

1. We note that R(phone book) •=. T(name) x T(address) 
x T (telephone) and R(name-salary) £ T (name) x 
T(salary); each relation involves T(name) in the 
cartesian product of which each is a subset. 

2. We take from each relation a member in which the 
names match and proceed to form a new relation 

in which members are subsets of T(name) x T(address) 
x T(telephone) x T(taxes). 

3. The new relation will contain that subset of the 
4-ary cross product above formed by following the 
rule in (2. ) . 

Let X=types(R(x))=domUR(x) , Y=types (R(y) )=domUR(y) , then 
the composition R(x)°R(y) is defined as 



R(x)°R(y) = {g:XUY->N T | 3 £ £ R(x) ,3h £ R(y) 



((Vt)(t £ dom g 



(t £ dom f+g(t) = f(t)) $ 



(t £ dom h+g(t)=h(t)))} (3-9) 

Alternatively, each g=f(Jh. The simple composition operation 
composes on all those data type names which are found in 
both R(x) and R(y) , and produces a new relation whose order 
is greater than or equal to the orders of the operand rela- 
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tions. Specifically if order (R(x) )= | domllR(x) | and order 
(R(y))= |domUR(y) | , then new_order=order (R(x)) + order 
(R(y))-|xnY|. 

A capability missing within simple composition is the 
ability to match data type names which are different, yet 
have intersecting images under T. For example, if Regis- 
tration) S: T (student) x T (subject) and R(phone book)& 
T(name) x T (address) x T(telephone) , the R(registration) ° 
R(phone book)={}=#. Such a composition may be necessary if 
an instructor wishes to call all his students in a particu- 
lar subject. To allow for this renaming, we define two 
functions X and p which apply to R(x) and R(y) respectively: 

A:X+N T ,X=types(R(x))=domUR(x) (3-10) 

p:Y+N T ,Y=types(R(y))=domUR(y) (3-11) 

X and p rename certain data types as specified by a user of 
the system. In the registration example, X (student) ="name" 
would yield a result & T(name) x T(address) x T(telephone) 
x T(subject); the dual result, (name)=student , would yield 
a result £T(student) x T(address) x T(telephone) x T(subject). 
In both cases the information would be the same, differing 
only in the perception of involved individuals as "names" 
or "students". Formally, we define extended composition as 

R(x) Cx ° p) R(y) = {g:(ranXUranp)+N T | 3 f £ R(x) ,3h £ R(y) 

((Vt) (tedom g-* 
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((Vu)(uedomf § A (u) = t-*f (u) =g (t) $ 

(fVv) (vedomh § p (v) = t-h (v) =g (t) ) ) ) } 

(3-12) 
In a set theoretic data management system, the most power- 
ful operation is composition, and as one would expect, is 
also the most complex to specify. Nonetheless, it is com- 
position, simple and extended, which allows selective 
merging by data types of relations. 
Reconstructability 

The decision of what data types are to be involved in 
any relation is a non-trivial matter. In particular rela- 
tions defined by (3-5) and (3-6) may be more "complex" than 
necessary. Assume for example, that a company records for 
each employee only his name, age, height, weight, employee 
number, salary, and years with the company. The relation 
R(employee) might then contain the member 



{<weight, 2 4 3> , <age , 36 > , <height , 5 ' 9"> , <name , J . Smith>, 
<salary , $22 ,000> ,<years employed , 9> , <man #,6532>}. 

While all this data pertains to "J. Smith", certain other 

elements may have no particular bearing on each other; it 

is not clear, for example, whether a $22,000 dollar salary 

is significant vis-a-vis the height 5'9". However, the 

M2=.ia]A£ name J. Smith and the age "36" tell a certain fact 

about J. Smith. The projections it f . Rfphone book) 

[name address) r J 
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Jl, .Rfphone book), et cetera, have been composed with 

(name ,age) r 

each other without giving us additional significance among 
the facts about J. Smith, except that such facts each be- 
long with him; but this is known already if the functions 
(name, age), etc. are within our purview. 

If we consider an office directory, however, the abil- 
ity to obtain the original relation by composition of its 
projections may be absent. Let R(phone book)= 

{{<name,Al> , < room, A- 5 > , <extn, 31 7>} , 

{<name, Al> , <room,A-5> ,<extn, 31 8>} , 

{<name,Andy>,<room,A-5> ,<extn,318>} , 

{<name,Andy> ,<room,B- 2> , <extn,442>} } (3-13) 

No set of projections (save the trivial case \ xame room ex ti^ 
can be composed to exactly reconstruct (3-13); spurious 
members would be coded. 

Given irr £(phone book) = { {<name ,A1> ,<room,A- 5>} , 

{<name,Andy> ,<room,A- 5>} , 
{<name,Andy> <room,B-2>}} 

and tt , ^ -,R(phone book) = { {<name ,A1> , <extn, 317 >}, 

{name,extn} vt J ' ' 

{<name,Al> , <extn,318>} , 
{<name ,Andy> , <extn,318>} , 
{<name ,Andy> ,<extn,442>} } 

then composition would generate the spurious members 
{<name ,Andy> , <room,A-5> , <extn,442>} , and {<name ,Andy> , 
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<room,B-2>,<extn,318>}. In fact, no set of projections on 
(3-13), when composed, yields R(phone book). The ensuing 
theorem provides a condition sufficient for relation recon- 
struction. The phone book example in (3-13) is not recon- 
structable from any set of its projections because we can 
find no single projection which would uniquely "tie together" 
the information stored there. In the employee relation, 
there exists, among others, a binary function which maps 
every name to an age, i.e. there is a function from names 
to ages. This fact assures us that, given a projection 
containing a name, weight, etc., the composition of the 
name-age function and this projection will yield a member 
of the relation R(employee) . The existence of such a func- 
tion f gives rise to a definition of relation reconstructa- 
bility: 

Definition: Let P={Tr y R(x) | Ys domUR(x)}, i.e. the set 
of all projections on R(x) . R(x) is reconstructable 
if and only if 

3 P' s P such that 
p ,° p ,p'=R(x). (3 . 15) 

With this definition in mind, we now state and prove 
a theorem sufficient (unfortunately not necessary!) for 
re construct ability: 

Theorem. 

If {S^S^ S 3 > is a partition of dom R(x) and 
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tt, q |C , J(x) is a "function", that is, if 
(. i> 7 3 J 

Vt 2j 3!T 3 (((T 2 eu s^^^s^RCx)) § C^g^^R (x)) 

§ (T 2 UT 3 ) £ 7r (S2US3) R(x)) (3 _ i6) 

then R(x) is reconstructable , and 



R 



(x) = '(s^s/W ° ^s 2 os 3 ) R ^ (3 . 17) 



Proof : 

If Lemma I of Appendix A is applied, then in (3-16) 

7T s 2 7T (s 2 us 3 ) R(x) = ir s 2 n(s 2 us 3 ) R(x) 



or 



V( S2 as 3 ) RO ° = V Cx) C3 " 18) 

and 

\s/ ( s 2 us 3 ) R W = T s 3 R W ^" 19 ^ 

Thus the function (3-16) can be simplified to 
Vt 2 3!t, ((t 2 e tt s R(x)) $ (t 3 e tt s R(x)) 5 

( T 2 U T 3 e ff (S 2 US 3 ) R W" C3 " 20) 

We now show that 1) any member of the left side of 
(3-17) is also a member of the simple composition on 
the right, and 2) that conversely, any member of the 
composition is also a member of R(x) . These two 
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steps constitute the proof of (3-17). 
I. Let g e R(x). The definition of projection (3-8) 
assures the existence of some f, e t\,„ ..„ ^R(x) 

and some f 2 e ir (s ^ s ->R(x) such that f s g and 

f 2 £ g. That is 
(3f 1 ,f 2S g)(£ 1 e ^ CSiUS2) R(x) § f 2 e ^g^s^Rfx)) 

Since dom ^ = SjUS 2 and dom f 2 = S 2 US., 

dom f-j^U dom f 2 = dom g = S,US 2 US, = dom L)R(x) . 
f^ and f 2 are functions; since the union of their 
domains equals the domain of g, f-ilJf? = g- The 
union of f and f-, however, is equivalent to the 
binary composition of f, and f ? , since 

(Vt e. dom g) (t e dom f 1 § t e dom f - -* 

f-^t) = f 2 (t)) 
Thus the element fi°f 2 = g for some g e R(x). 

1 e 7T (s 1 us 2 ) R(x) and f 2 e 7r (s 2 us 3 ) R ^ x ^ 

such that 

f l° f 2 e ^(S^SpRW ° 7T (S 2 US 3 ) R(X)) - 
f 1 is g restricted to S,US 2 for some g e R(x) . 
Consider an f^ which is g 1 restricted to SJJS 



II. Let f 
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for some g 1 e R(x) . Since TT.g us ^R(x) is a 

"function" in the sense of (3-16), f 2 restricted 
to S 2 = f 2 ' restricted to S 2 , so g = g' . Hence, 

for all f, e t\ (s us -jR(x) and for all f 2 e 

■n ( s nR(x), there exists age R(x) such that 

f f- = f'f, = g. Thus all elements of the 

composition of (3-17) are also members of R(x) . 

Q.E.D. 



Knowledge that a relation is reconstructable can aid 
in retrieval operations on the data-base B. Given the 
relation 

R(phone book) s X T(i) 

i e {name , address , telephone} 

and the necessity of telephoning someone named "John", 
then the operation 

it, , -, ( R(phone book) ° { {<name , John>} }) 
{phone} ^ 

will yield a unique phone number if John has only one 

phone. The above operation for any person would yield 

a unique phone number if there were a "function" in the 

sense of (3-16) from names to phone numbers. Note however, 

that if John has two phones then the above operation will 

vield a set of two elements. 
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Even if we have no function from names to telephone 
numbers, this does not imply that retrieval of a unique 
phone number is impossible. For example, if every pair 
of names and addresses is "mapped into" a unique phone 
number by the "function" of (3-16), then by specifying 
both John and the additional information that he is cur- 
rently at 10 Main Street, we can retrieve his unique phone 
number. The operation 

■"■/ u \( Rfphone book) ° 
{phone } v ^ J 

{{<name , John> ,<address ,10 Main Street>}}) 

will yield the unique phone number if the above condition 

holds . 

2. Ordered Set Theory 

In considering how we might implement a relation, we 
must come to terms with the most pervasive real-world 
consideration to which we are bound, namely order . Order 
is imposed in almost all environments; symbols and 
notation will be written in a linear order, and a 
representation of a set is free of order only by intention. 
Most extant computers employ a sequential numerical ordering 
scheme, the most common of orders. Hence, we must conform 
to this constraint of order and include this notion somehow 
within our framework of set-theoretic concepts. 
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An ordering !1 is a bijection (one-to-one, onto 
mapping) from an index set I to a set S, each set 
containing k elements. The index set I contains 
the successor of all but one of its elements. 



ft 



I S where 3jel|j + £l $ V^j f ieI i + e i (3-21) 



Paraphrased, ft assures us that we can step in some 
well defined sequence over the index set (via successors). 
Elements of S are thus associated with an ordering 
procedure . 

With <a,b> defined as {{a},{a,b}}, we define a special 
case of ordering, the tuple. We already have an intuitive 
feel for a tuple, e.g. (a,b,c). We recognize that the 
physical position of an element is as much a piece of 
necessary information as is the element itself. The tuple 
(b,b) can exist, for example, while the set {b,b} cannot. 
But a tuple can be viewed as follows: 

A tuple x is an ordering ft T where the index set I T 
has the special properties that it is a subset of 
the natural numbers and contains the element 1 if 
non-empty. Formally 
r:ft T :I T ^S where L£ N, 3i e i ->l E T 3keI T | 

k + £l T $ Vi = k, iel +i + el (3-22) 
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That is, a tuple is the special ordering from {1 , 2 , 3 , . . . ,n} 
to the n elements of the range set. In set notation, a 
tuple is represented as 

(t 1 ,t 2 , ... ,t n ) = {<l,t 1 >,<2,t 2 >, ... ,<n,t n >} 

A tuple is readily represented on a real computer, 
since the order of a tuple coincides with the most prac- 
tical implementations of order. However, an arbitrary 
ordering 0. may not be easily representable ; therefore, at 
some point, if no other assumptions are made, we must use 
tuples (or whatever real-world form of ordering to which 
we are bound) . 

As an alternative to a given environmental ordering 
we define an entity called an explicit element. 

An Explicit Element e is an element which is 1) 
meaningful in a global sense, and 2) recognizable 
independently of the context in which it is found. 

[3-21 
For instance, if the word "fremitus" appeared only 

once on this page, we could locate it unambiguously, 

independent of the way in which the words on the page are 

searched. We can also determine its meaning free of the 

context of this page. Note that any element can become 

explicit by merely restricting the context of consideration 
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sufficiently; if we search only one word it must be explicit 
since no duplication exists as long as the word is 
meaningful. The requirement of global meaning is significant 
in computers, since many words are not meaningful to a 
given search request (e.g. the octal word 777777 has no 
meaning when viewed as four ASCII characters.) 

Often we wish to make the elements of N T and N R (see 
section 1. of this chapter) explicit elements. It is 
desirable that these names be recognized in a context-free 



sense whenever they appear. Consider the set E of explicit 
elements where eeE -> eeN T - With E we define another entity 
which will be reencountered later in the discussion. 



An Explicit Naming Tuple is a tuple whose range 
consists entirely of elements e, where e£N T and 
e is an explicit element. 
ENT: « T :I T -*• U ,e 2 , ... ,e n > e^N^eeE (3-23) 

In effect, an ENT defines an arbitrary order on the ele- 
ments oi' E which will prove useful. Since ENT is a 
function, its range is totally ordered. 

The ENT function is intimately tied to the definition 
of a relation. A relation R(x) assumes the form 

R(x) = {{<e 1 ,d 11 >,<e 2 ,d 21 >, ... ><e n ,d nl >}, 
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{< ei ,d 12 >,<e 2 ,d 22 >, ... ,<e n ,d n2 >}, 
{<e l' d 13 > <e 2* d 23 > * "■ ' <e n' d n3 >} 



{< ei ,d lm >,<e 2J d 2m >, ... ,<e n ,d nm >}} (3-24) 

Since R(x) is a set, the subscripts identify, but do 
not order the particular elements involved. Note that 

dom UR(x) = {e, ,e~, ... ,e } (3-25) 

Consider the class of functions 

ENT: U|l<i<n}-»-(l to 1, onto) domVR(x) (3-26) 

There are n! possible ENT functions for any R(x) ; each such 

ENT will be denoted by a subscript. We take in particular 

some ENT, such that 
k 

ENT k (R(x)) = {<l,e 1 >,<2,e 2 >, ... ,<n,e n >} 

= (e 1 ,e 2 , ... ,e n ) (3-27) 

The subscript k serves only as an identifier for the 
particular ENT chosen. An equally valid choice might be 

ENT 
ENT k (R(x)) and ENT k ,(R(x)) are distinct bisections on the 
same relation. Each ENT function is an arbitrary ordering 
of the data type names in dom(jR(x). The particular order 
is specified by which of the n! possible orderings is 
chosen. 



k , (R(x))-(e n ,e n _ 1 ,e n2 , ... ,e 2 ,e 1 ) (3-28) 
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As defined in (3-27), an ENT is a function with respect 
to a relation. The particular k chosen depends on the organi- 
zation of R(x) desired. This indicates how the ENT empiri- 
cally defined in (3-24) is chosen. The explicit nature of 
the elements of domUR(x) is, of course, maintained. 

At this point, we introduce some additional functions 
which transform R(x) into another entity. The transformations 
will also exhibit the following characteristics of the rela- 
tion R(x) . 

1. Given a data element d Np, we can determine a type 
with which it is associated. This is possible 
since each member of a relation R(x) is itself a 
bij ection : 

t: e+d | teR(x) $ (Vi,j*n) dom t^dom t. (3-29) 

t" 1 , in turn, maps d onto e. Note that since t 
is a bijection, we are always a unique e given 
a specific d. 

2. Given an e and an R(x) we can determine all instan- 
ces of d (i.e. the exact subset of N D ) which corres- 
pond to that e. These are merely the mappings t 
over all of R. 

3. Every element of R(x) , by virtue of the fact that 
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R(x) is itself a set, indicates a relatedness 
among its members. That is, 

row: x "is related to" y where x,yeran t, 

t e R(x) (3-30) 
4. Every member of R(x) includes an ordered pair 
for every e. The d's in these pairs are also 
related by virtue of their association with 
the same type e. 

column: x "is related to" y where x=t . (k) , 
y=t.(k) for all i,j<m and for 
all k<n (3-31) 

The nature of relatedness expressed in characteristics 
three and four is at this point intuitive, but will 
become clearer as transformations are performed upon 
members of R. The names "row" and "column" are used to 
indicate that when notation such as in (3-24) is used, 
relatedness exists by virtue of the physical structure 
of rows and columns. 

Wc define a function called Tuple with Explicit Naming 
Tuple (TENT) : 

TENT: t+t' | teR(x), t' = t ° ENT (3-32) 
More specifically, consider a given ENT, R(x) . Then 

TENT k (t) = t ° ENT k (R(x)) |teR(x) (3-33) 

Note that both the domain and range of TENT, are functions. 
The domain is a function from e to d; the range is a tuple. 
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Using the notation for R(x) in (3-24), we can formally 
express a typical TENT: 

ENT K =(e 1 ,e 2 , ... . e n ) [k arbitrary] (3-34) 

TENT k (t 1 ) = {<e 1 ,d n >, ... ,<e n ,d nl >) ° 

{<l,e 1 >, ... ,<n,e n >) 
={<l,d 11 >, ... ,<n,d n >} 
=(d llf d 21 , ... ,d nl ) (3-35) 

We note that the elements of the TENT are ordered in a 
fashion analagous to that of the particular ENT^. If k' 
from (3-28) were used instead, the TENT would appear as: 

TENT k ,(t 1 )=(d nl ,d n _ 1)1 , ... ,d 21 ,d n ) (3-36) 
It should be clear that each of the TENT's (with 
respect to a given relation R(x)) will each be ordered 
with respect to the ENT, chosen to order the given R(x) , 
since 

Vi,j lli,Jl m dom t.=dom t-= ran ENT (3-37) 

+■ v» 
In general then, for the R(x) of (3-24) the i TENT: 

TENT k (t.)=(d li ,d 2i ,d 3i , ... ,d ni ) 

THNT^Ct^^J^.d^^-.d^^i, ... ,d n ) (3-38) 

and so on for any choice of ENT. 

Note that we preserve the same content between 

a TENT, ft.) and its ENT, as with the element t. of R(x) 
k^ i J k x 

itself. This follows since all derivations are bijectional, 
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and it is possible to "go back". Thus we seek a structure 

which will include all TENT. 's and the ENT, . This structure 

k k 

would then contain all the information found in the relation 
R(x) itself. 

Therefore we define a sort on the various TENT's 

SORT(R(x)) : {j | l<j <m}+ (1- to- 1 , onto) 

{TENT(t) |teR(x)} (3-39) 
There are m! possible ways of ordering the m TENT's derived 
from R(x) . SORT is esentially a second arbitrary order 
placed upon the relation. However, there are a few standard 
SORT mappings which are used more frequently than others. 
The one used in GOLD STAR is called a lexicographic sort. 
We define lex ordering of TENT's as follows: 

TENT k (t x )-^ (lex less than) TENT k (t ) iff 

(3i)(l<i<n $ (*j)(j<i-TENT k (t x )(;j) = 
TENT k (t y )(j)) § 
TENT k (t x ) (i)<*TENT k (t y ) (i) (3-40) 



where 



TENT k (t )(p)= the p th element of the 

th 
S TENT 



Note that the < operation is determined by the ENT, chosen 

■f" Vi 

in the sense that the i element o; 
by the orderings ENT,. For example. 



■f" Vi 

in the sense that the i element of the TENT is determined 
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Let 

TENT(1)=(1,2,1,3) 

TENT(2)=(1, 1,1,1) 

TENT(3)=(2,1,3,3) 

TENT(4)=(2,1,3,2) (3-41) 

be determined a relation 

SORT. (the TENT's)= (TENT(2), TENT(l), 

J. CX. 

TENT(4), TENT(3)) 
For example, then, 

TENT (4)4 TENT (3) since for i=4, j=l,2,3 
TENT(4)(1) = 2 = TENT(3)(1) 
TENT(4) (2) = 1 = TENT(3) (2) 
TENT(4)(3) = 3 = TENT(3)(3) 
TENT(4)(4) = 2 < 3 = TENT(3)(4) 
Lex ordering, then, is the intuitive order where the first 
component of the TENT's is most significant, the second is 
next most significant, etc. The importance of ENT^. is in 
the determination of which is the first component, which is 
the second, and so on. 

We now define what appears as a trivial construction, 
the QUART: 

QUART = (ENT k (R(x)), SORT(R(x))) (3-42) 
(QUAsi RelaTion) 
For a typical relation R(x) as defined in (3-24), 
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QUART(R(x)) - 

(.1.6,, e^j ' ' ' '^nll'zl' *"* * nl ' 

( - d 12' d 22 d n2^' 

• • * 

• • • 

• • • 

C d lm> d 2m> •■• » d nm» C3-43) 
The construct QUART has two noteworthy properties, over and 
above those possessed by R(x)) itself: 

1. Two arbitrary orders are imposed upon the 
relation, namely ENT k (R(x)) and SORT(R(x)). 

2. The elements of ENT appear only once, 
giving a "factored" effect. This is highly 
desirable since by the definition of 
explicit elements, we can now consider a 
QUART as a context of consideration. (See 
3-23). The relation in its proper form 
has redundant occurances of the explicit 
elements, which limits our context. When 
transformed to a QUART, we can unambiguously 
identify the e's, and hence ease the search 
for information. 

Note that QUART (R(x)) retains all the information found in 
R(x) and discussed previously. By following the various 
bijections created in the derivations we can freely translate 
one form of information to another, e.g. 
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1. Given a d, find an e, e i = ENT^TENT^ 1 (j ) (d^ ) 

2. Given an e, find the d's associated with it 

d' = {TENT, (j) (ENT" 1 ) over all j's} 

3. Each TENT relates all d's with it. 

4. The d's defined above relate all d's of a 
given data type. 

The notation used in (3-43) lends itself to an even 
clearer form: 

Ik ll '" fs. C3 " 44) 

d ll d 21 ••' d nl 

d 12 d 22 ••• d n2 



d„ d d 
lm 2m nm 

This form is already familiar from (2-1) and (2-2-d). As 

expected this form represents a relation. 

Henceforth, where a QUART is mentioned, it will be 

assumed that it is in effect a relation. We refer to its 

structure as follows: 

CENT, or PENT: Two computer representations for 

the types, or e's in our formulation. 

(CENT is Character ENT) . 

(PENT is Pointer ENT) . 

Order: The number of elements in the ENT and each 

TENT (= |dom 1/r(x) |= n) . 
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Length: the number of TENT's in the QUART, which 
was in in our formulation. 

When we mention the term "relation" henceforth, we mean a 
relation stored in some form other than a QUART. This section 
has discussed how any representation of a relation (which 
represents the abstract notion of a relation in (3-24) 
can be transformed into a QUART. Other relational organiza- 
tions are considered in the next chapter. 

One final concept remains: that of a successor in the 
context of a QUART. We have adopted the view that the successor 
of a TENT is the next TENT according to the SORT function 
adopted. This follows either the specified TENT, if it is 
part of the QUART, or follows the place where the TENT would 
have been inserted if not already included. More succinctly, 
the successor operation is a least upper bound operation. 
For example, given 

a b £ 

111 

13 1 

13 3 

2 12 
successor [ (1 , 3, 1) ] = (1,3,3) 
successor [ (1 , 2 ,1) ] = (1,3,1) 
Further examples of QUART operations are found in 
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CHAPTER IV 

AN IMPLEMENTATION OF GOLD STAR 

This chapter discusses the rationale for one GOLD STAR 
implementation. The system is not of the direct transplant 
variety, since we have chosen to utilize some features 
peculiar to the present target computer -- the GE/64 5/MULTICS 
Furthermore, the algorithms mechanized for the MULTICS sys- 
tem may be less suited to environments other than ours. 
Despite certain shortcomings, we feel it advantageous to 
pursue the cogs and machinery of GOLD STAR/MULTICS. 

1. DSM Modules 

Representation of Data Elements 

Every computer system faces the problem of dual repre- 
sentation of data elements : one representation allowing fast 
internal operation of the programs, and another suitable for 
human consumption via printed or graphic input/output oper- 
ations. Classically, i.e. in "algorithmic" languages, the 
formats for user data have been dictated by " representation 
types " such as integer, floating point, logical, and fixed 
point data found in FORTRAN systems. In GOLD STAR the term 
"data type" refers to classification of data according to 
some attribute assigned by the user (e.g. "cities" , "last 
name") , and not according to some internal code peculiar to 
the computer environment. To the user, this distinction 
between "representation type" and "data type" is significant: 
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in the former case, environment idiosyncrasies force extra 

meaning on the data due to representation, while in the 
latter case all semantics depend upon the user's own class- 
ification of the data. 

While the user views his data elements only in terms 
of data type, there still remains the issue of efficient 
internal representation. Although relatively transparent 
to the user, the techniques utilized to increase the speed 
of operation merit further scrutiny. Internally, all user 
data is manipulated in the form of word- length bit string 
tokens, which we refer to as reference numbers . The task 
of binding strings to reference numbers is performed by a 
class of GOLD STAR sub-programs called data strategy modules , 
or DSM ' s . 

The Binding of Reference Numbers to Strings 

At the time a user creates a new data type within GOLD 
STAR, he usually perceives or assumes a total ordering on 
the elements of a data type. The method of assigning refer- 
ence numbers to strings begins with the requirement that 

/'< ! i,' toi-al ordering on members of any data type is 
completely preserved by (i.e. isomorphic to) the 
total ordering on the assigned reference numbers. 

\\q further require that valid comparisons between data items 
exist only if the comparands are numbers of the same data 

type . 
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Binding of Reference Number Via Alphabetic Order 

The module dsm_astring binds strings to reference 
numbers in such a way that ascending reference numbers 
preserve alphabetic order among the data elements. The 
notion of alphabetic order is deeply ingrained in most 
individuals, and is significant in that it is a common 
ordering scheme applicable to arbitrarily large lists of 
strings of any length(s) . Universal usage of alphabetic 
order requires a facility, i.e. dsm_astring, for its accom- 
odation; dsm_astring serves this purpose. 

For each data type it manages, dsm_astring maintains 
a binary tree in which data elements are stored and from 
which they are retrieved. Because collating sequences in 
ASCII and otner codes preserve alphabetic order, dsm_astring 
is able to compute order-preserving reference numbers direct- 
ly from the input character strings. The exact method by 
which this operation works will become clearer if we follow 
the procedure invoked to perform a binding operation on the 
data type "names". (By binding we mean inserting a new item 
into a DD area and associating an appropriate reference 
number. ) 

The user creates the data type "names" via a call to 
mgr$new_data_type and initializes the header shown in 
Figure 4-1. (Kach data type is stored in a separate segment 
in the MULTICS system, and its size is controlled via the 
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"allocate" and "free" statements in the PL/1 language.) 

The header contains information required by GOLD STAR for 

system calls, as well as pointers to the tree root, the 

head of a successor chain, and counters used to indicate the 

number of free and empty cells. The user establishes to 

GOLD STAR that the DD area "names" will be managed by dsm_ 

astring; he does so by specifying the DSM name in the call 

to new_data_type. Subsequent references to "names" will 

automatically invoke this DSM. 

Figure 4-2 illustrates the logical changes in "names" 

resulting from the insertion of "Ezra". Two actions occur: 

the root pointer is set to the address of "Ezra", and the 

canonical root reference number is assigned. The root 

reference number is defined as 

r n- 2 

re£ root = 2 

where n = the number of bits in a full word. The choice 

of this quantity as the root reference number implies there 

are as many positive reference numbers greater then re f root 

as there are less than ref . , and facilitates the forma- 

root 

tion and maintenance of a tree symmetrical about the root. 
In subsequent action, the successor chain head is set to 
"Lzra" and the number of cells active in "name" is incre- 
mented by "1". As "Ezra" has neither descendants nor a 
successor at this point, these pointers in the data item 
are null. 
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Figures 4-3 and 4-4 illustrate the method by which 

dsm_astring computes reference numbers. In Figure 4-3 

the name "Claude" is inserted in the tree as Ezra's left 

descendant, since "Claude" is lexicographically less than 

"Ezra". The reference number of "Ezra" f = ref ) is the 

root 

only reference number at level 1 in the tree. Reference 
numbers for descendants of an item present in the tree are 
computed as follows. 

A candidate data item for insertion is compared with 
the root note item. If the candidate is less than the root 
(according to alphabetic ordering) , then one of three situ- 
ations can occur. If the root item and candidate are equal, 
then the candidate is already present; search stops. If 
the root item's left descendant is non-null, then it becomes 
in effect the root, and search begins at that point. If 
the root item's left descendant is null, then a number of 
words required to store an item are allocated, pointers are 
chained and the new reference number is computed via the 
formula 

r = r 2^"^ 

lef t_dcsccndant parent 

where d is the maximum depth of the tree, and i is the depth 
of the tree at which the parent node appears. 

If the candidate item is alphabetically greater than 
the root item, then a procedure analagous to the above pro- 
cedure for left descendants is executed, on the right, with 
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Figure 4-3: Insertion of "Claude" in Data Area 
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Figure 4-4: Insertion of "Milton" in Data Area 
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T — T + Z 

right_descendant parent 

Note that the reference numbers for left and right descen- 
dants will be less than and greater than, respectively, 
the reference number of the parent node as long as i _f_ d. 
When i exceeds d, this implies that no more items may be 
inserted in the tree below the current "working node". The 
exact reasons for this limitation result from the fact that 
the level of the tree i occupies one bit position in the 
reference number, with a left turn at level i being indica- 
ted by a 0, a right turn by 1 in bit position i in the ref- 
erence number. Thus a reference number of d bits allows at 
most d levels to a binary tree. A more complete discussion 
of dsm astring and tree-overflow is found in Appendix A. 

The module dsm_astring is ideally suited to the task 
of binding reference numbers to alphabetically ordered 
strings, since insertion and deletion of items requires no 
reshuffling of data elements. The ability to delete and 
insert items without restructuring is an important consid- 
eration, but perhaps the greatest value of the tree search 
is the fact that for a data type of n members, the average 
search time is KJiog^n where the constant K is independent 
ol~ n . 

Binding of Reference Numbers to Integers 

Like the ordering on alphabetic strings, an ingrained 
ordering is the consecutive nature of the integers. Classi- 
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cal data management systems have recognized this important 

ordering, but only by providing a specific internal computer 
representation. As mentioned at the beginning of this sec- 
tion, COLD STAR treats all data types in relation only to 
a perceived ordering. Thus a module dsm_integer maps data 
elements representing integer ordered strings into fixed 
length bit strings. (The dsm_integer module uses the same 
internal format for integers that a classical data manage- 
ment system would. That is, strings made up of the charac- 
ters "0" to "9" are transformed into internal machine binary 
representation. Thus, GOLD STAR converts character strings 
representing integer data, to binary numbers representing 
integers to the target computer. However, "integer" is not a 
data type; data types such as "population", "number_of_ 
children" etc. are examples of data types utilizing the 
integer o rdcr i ng on strings.) 

The Binding of Reference Numbers to Strings Where a Well- 
Ordering of String is Inapparent from the Alphabetic Order 

Two other data strategy modules complete the data 
representation repertoire of GOLD STAR. Very few data 
types o {' large membership ever utilize an ordering scheme 
other than the two previously mentioned, simply because 
humans find memorization of many ordering schemes incon- 
venient. However, certain data types of small membership 
size (.e.g. the months, or academic titles) follow ordering 
relations not directly discernible from the data elements. 
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In cases where the ordering is static (i.e. no insertions 
in the data type, as in the case of "months of the year") 
the module dsm_table assigns indices in the table to data 
elements. The data type "months of the year" would map 
January in 1, February into 2, etc. For small data types 
which are of dynamic rather than static nature, (e.g. the 
collection to titles in a company) a module dsm_chain is 
provided. dsm_chain allows insertion and deletion of items 
which are maintained in order on a single threaded list. 
An inserted item assumes the reference number 

1 r <> 
r — — ( r + r ) 

2 v predecessor successor " 

2. RSM Modules 

Every relation in GOLD STAR is stored in its own seg- 
ment, and each such segment is organized and managed by a 
program known as an RSM, or relational strategy module. An 
RSM operates on one particular physical organization of 
relations; in most instances the number of relations will 
far exceed the number of separate relation organizations. 

The choice of which RSM is the most likely candidate 
for creation and maintenance of any relation is probably 
the user's greatest single problem. He must decide which 
structure is most suited to operations involving the rela- 
tion. If the relation is large, will it require simple 
organization due to storage limitations? Will the relation 
be modified frequently? Is there more than one frequently 
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used lexicographic sort o£ the relation? 

Among these questions, there is a hint of the magni- 
tude of problems involved in the choice of an RSM for any 
relation. Like the DSM choice, several factors are in- 
volved, and since most CPU time will be incurred during 
RSM operations, the judicious choice of an RSM is critical. 
The more significant factors are: 

A. The number of different lexicographic sorts 
with respect to which the relation will be 
accessed. 

B. The frequency of use of the relation. 

C. The probability distribution expressing 
relative access to each item. 

D. The number of tuples in the relation. 

E. The envisioned dynamic nature of a relation. 
If insertion and deletion of relation mem- 
bers is frequent, then some RSM which chains 
items together by some ordering other than 
storage location is called for. 

P. The basic structure of the relation itself. 
A many-to-one or one-to-many relation may 
have to be managed entirely differently 
from a nearly one-to-one relation. For 
example, a relation in which names have 
several telephone numbers is many-to-one. 
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Thus far, these guidelines have been enunciated, but 
very little is known (other than empirical testing) about 
their measurement. Our efforts this past year have pro- 
vided an RSM managing quarts, and other possible RSM struc- 
tures. We decided that all RSM's, in addition to normal 
operation entries, should contain entry points for convert- 
ing between a quart and the particular relation structure 
managed, and vice versa. This allows a user to consider 
several alternative RSM's and test the operation of each; 
the user enters his relation once, and can then proceed 
among the desired RSM's via subsequent calls to convert_to 
quart and convert_to_relation. Morever, this double struc- 
ture format involves only a small amount of code compared 
to most operations. 

The following constitute the RSM repertoire in the 
initial version of GOLD STAR. 

A. RSM_Q -- assumes operands are quarts, but 
treats them as non- transient members of the 
function R. 

B. RSM_WQ -- assumes operands are quarts, but 
does not provide for keeping these quarts 
beyond the life of a process. (See next section). 

C. RSM_TREE (under consideration) 

While both RSM_Q and RSM_WQ manage extremely simple 
relation organizations (which are lexicographically ordered 
matrices with some trimmings) they offer the least power of 
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all RSM's. Sorting, dynamic insertion, and dynamic dele- 
tion all require creation of new quarts which hold the 
modified relation. In cases where large relations are 
involved, these operations, or other RSM operations re- 
quiring these services as subfunctions (composition, union, 
intersection, etc.) may become extremely costly and time- 
consuming. Moreover, in on-line operations, searching for 
or modifying even a single tuple in large relations may 
disallow quick real-time response. For certain relations, 
it may prove expeditious to use a tree structure similar 
to those of TDMS or the MacAIMS project at M.I.T. 
While these structures require more space to implement, 
addressing an item depends not upon restructuring, but 
rather upon the use, manipulation, and modification, of 
certain pointers at each node. 

The RSMJVQ 

This is the module which performs the basic system 
operations on quarts only. The reader is referred to 
Appendix I for some examples of such operations. A few 
interesting issues have arisen in the implementation of 
the Working (Juart RSM. 
A. Union, Intersection, Difference 

These operations all use fundamentally the same code 
(see figure 1-5 for flow chart). A key issue, however, 
was whether to sort the second input with respect to the 
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first before operating, or not. To solve this dilemma, 

Let £, = length of first quart 
i ? = length of second quart 
= order of each quart 

S = a "search", or the comparing of one quart 
element with some given entity. 

We know that a simple token sort of the kind used in RSM_WQ 

takes a number of steps 

2 
#S(sort) = I log£ (on the average) 

Once the quarts are both sorted alike, we can recognize a 
best case in operating. 

When the first TENT of one quart is lexicographically 
greater than the last TENT of the other, then it is possible 
to determine this by only examining the first element of 
each of those TENTS; we can then determine the union, inter- 
section or difference. For example, given 

a b c_ a b c 

12 3 10* 11 12 
4* 5 6 13 14 15 

since 10 is greater than four, we know the intersection is 
empty, the difference is the first quart, and the union is 
the combination of all TENT's of the two. 

We can also recognize a wors case (see flow chart) 
where we must examine every element at least once during 
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the steady progression through each quart. This yields 

2 < #S(operate) < (J^ + £ 2 )0 

Hence, to sort and operate, we get, as an average, 

f) 2 
#S(sort $ operate) = (^ + i 2 )j + £ 2 log£ 2 

In assessing just how many comparisons are needed to oper- 
ate in an unsorted case, we again examine a best case: 
For each TENT in quart 1, we need only search the 
entire length of quart 2 once (JU/2 average searches) 
during which we find an equal TENT; that means that 
the first match found for each of the TENT elements 
is the only one. An example of this would be: 

quart 1: a .k£ 2: b c a 

12 3 2 3 1 

4 5 6 10 11 12 

7 8 9 5 6 4 

Here, if we start searching the a column in the second 
quart, we need go no further since the b and c columns 
will also (and always) match (presuming a match was 
found at all in a). This best case requires £,(Jl 2 0)/2 
searches . 
We can also ascertain a worst case: 

For each TENT in quart 1: every column in quart 2 
must be searched (2,-0/2 average searches) for each of 
the columns in quart 1. That is to say, when a match 
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is found in column a, one is not found in b and a 
must be searched for again, with the worst case 
being once for the entire length of a (if all of a 
is the same). This case takes Ji^O 2 /2 searches 
on the average. 
Let us now compare the two cases : 

Sort then operate No sort 

2 + £ 2 log 2 5 #S 5 (£ 1 + £ 2 )0 + 2 £ 2 log£ 2 (Ji 1 £ 2 0)/2 < #S 



* (£ 1 £ 2 2 )/2 



On the average 



(£ 1 +£ 2 )0/2 +£ 2 2 log£ 2 £ 1 £ 2 2 /4 

letting £ 1 =£ 2 =£ approximately 

£0 + £0 2 log£ £ 2 2 /4 

dividing each by £0 

1 + 01og£ £0/4 

for £=100, 0=3 
1+6=7 75 

for £=10, 0=3 
1 + 3=4 7.5 

So, for most configurations of quarts, the sort oper- 
ation is well worth the tune. That is why that course of 
operation was chosen. 
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B. Composition 

A first consideration in composition is how to specify 
it. We face a number of decisions: 

1. Compose or not on columns with equal CENT'S 

2. How to indicate composition on columns with 
unequal CENT'S 

3. Whether or not to keep the resulting column 

The scheme adopted of binding all CENT'S involved to a user 
supplied vector of names has the following effects on the 
decisions : 

1. We compose by equality of bindings, not CENT'S. 
This allows a choice on columns with equal 
CENT'S, since they can easily be bound to 
themselves . 

2. By binding unequal CENT'S to equal names, we 
can choose this alternative. 

3. This is not optimal; all columns are kept. 
Projection will elimanate unwanted columns. 

The equivalence vector also presents the easiest form to 
deal with on a practical level; a complete equivalence 
relation indicating classes of equivalence by CENT would 
be very difficult to specify syntactically. 

The equivalence vector for R(x) , ° ^R(y) (see Chapter 
III) is the concatenation of ENT K (X) and ENT K , (p) where 
K and K' arc the sorts specified by the user. To 
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output_expression) 

where the input expression is a regular expression which 
is "matched" to the input, and the output expression dic- 
tates how to transform the bindings to an output string. 
The regular expression syntax considered is as follows: 

Delimiters are: blank, and parentheses 

Operators are: or (|), closure (*) , not (~) , and 
concatenation (e.g. a|b matches a or b , a* matches 
any number of a's, "a matches anything but a, ab 
matches ab) . 

Special characters are: • (matches any character), 
$ (matches any number) , ? (matches any upper case) , 
! (matches any lower case) , < (matches the beginning 
of a line) , > (matches the end of a line) . 

Bindings are made by /numeric, variable/ and are 

created only if the numeric expression is satisfied. 
The format of the numeric is n+ (n or more charac- 
ters in the string to be bound), n- (n or less), 
and combinations of these using concatention or or . 

Some examples are : 

RE Input Bindings 

<a* |b*/ 5-,x/> aaamp x ->■ mp 

same aamnopqr none (will not match) 

a|bc/x/$# bcmno2 31 x -> mno 
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The user is referred to explanations o£ QED for fur- 
ther elucidation, and to Appendix C for a formal syntax 
definition. 

The main drawback to implementing such a parser is the 
lack of efficiency that code doing these tasks will have. 
It is necessary to, in effect, compile machine code from 
these regular expressions and execute that code. No attempt 
has yet been made to implement this design, although it is 
hopeful that the task is not too complex to undertake. 

Protection and The Projector (See Chapter II, Figure 2-3 for 
the part the projector plays in the system structure) 

A situation that is sure to arise is that of having 
privileged information which is not isolatable to a single 
data area or relation. For instance, the relation name- 
salary- contract-percentage might exist; salaries are con- 
fidential while contract and percentage are not. In effect, 
we are in the position of wanting to allow access to a 
projection of a relation. Given the MULTICS protection 
scheme (see Appendix D for a full discussion of protection 
issues), a need for a "projector" arises. This projector 
would operate in a ring higher than that of the user. The 
user would then have to request (through certain stringently 
defined entries) the projection he was entitled to via the 
proj ector . By having the relation in question only permitted 
to the higher ring of the projector, protection is gained by 
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limiting the user to accessing the relation via a well set 
forth sequence of code, the projector. 

The problem arises of some users of GOLD STAR having 
ring permission as high as would the projector. This brings 
about a manifestation of the ring uniqueness limitation 
(Appendix D) of MULT1CS: that a user in your ring (here, 
that of the projector) must be given access to a segment 
on an all or nothing basis; you cannot force a gate upon 
him. 

Until such time as MULTICS allows gates to be imposed 
on a caller in the current ring, we must content ourselves 
with protecting on a projection basis only against those 
users in inferior rings to the system. This is the job of 
the projector. 

The Common Usage Descriptor (CUD) (See Chapter II, Figure 2-3 
for an indication how the CUD fits in the system structure). 

The purpose of the CUD is to provide a description of 
the most common usage a relation receives. For instance, 
if a telephone directory were always to be accessed by 
"given a name, find an address and telephone" (rather than 
"given an address....", or "given a number...."), the CUD 
would somehow describe this and indicate that the ideal 
sorting of the directory would have name as its most ordered 
column . 

No design or plans have yet been made for the CUD, but 
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it is felt that as the complexity and number of RSM's pro- 
liferates, a device like it will be needed for efficiency. 

The next chapter will now explain the specifics of 
the implementation just described: the subroutine calls, 
the programming considerations, and an example of the use 
ol~ GOLD STAR. 



CHAPTER V 
PROGRAMMING GOLD STAR 

1. The User Interface 

In this part of the thesis we will outline in detail 

the specific functional calls available from the GOLD STAR 

system. A few subjects are worth noting before a complete 

description is presented. 
Arrays 

GOLD STAR permits both pointers and arrays of pointers 
as input. This is an efficiency matter considered in 
a later part of this chapter, section 2. 
Nesting 

Since all calls in GOLD STAR are functional, calls can 
be nested. This means that whenever the result of an 
operation is appropriate, the function can be used as 
an argument to another call. For example, with a, b, 
c , d as pointers , 

(a) a=mgr$union(b , c) 

(b) d=mgr$union(mgr$intersect (a,b) , c) 
Note that all characteristics of the result will be 
determined by the left-most argument. Hence in (a) 

a will be "the same as" b (meaning if one is a quart, 
the other is a quart, likewise for relations; or, that 
the order of the CENT elements for a is the same as 
in b) ; while, with (b) d will be "the same as" a. 
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One other point: since PL/1 prevents us from returning 

arrays from a function, a pointer to an array is re- 
turned. We denote this by (p->)A where A is an array 
of pointers. This will affect nesting and assignment; 
a typical array nesting would be as follows 

D=mgr$union(mgr$ intersect (A,B)-HE , C)-*E 

A,B,C,D,E arrays of pointers, E based 
Notation 

1. All upper case variables denote arrays 

2. All lower case variables denote scalars 

3. (p->)A indicates a pointer to an array 

4. {} denotes a choice of elements contained 

5. [] denotes what is contained is optional 

6. "option" denotes a character string of one to 
three characters which can assume the indicated 
values as its characters 

7. Underscored variables are character variables 
Semantics 

1. q 5 Q refer to quart pointers 

2. r § R refer to relation pointers 

3. All arrays in a given expression using the GOLD 
STAR calls must have a lower bound of one and 
and identical upper bounds 

4. Meanings of options are: 

F = delete first argument when done (RSM) 
S = delete second argument when done (RSM) 
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I = insert item being referred to (DSM) 
D = delete item being referred to (DSM) 

(I overrides D) 
1,2,...., 9 = use this column of the quarts 
supplied as input (see get_data§successor_data) 
(DSM) 

E = treat first argument exactly as if it were 
expand_quart (argl) -- this is an efficiency- 
feature (DSM) 

5. Only one DSM or RSM can be used per operation. 
This means that the RSM or DSM dictated must be 
the same for all elements of the arrays which 
determine the DSM or RSM to be used. 

6. Non-existent optional arguments are the same as 
if NULL were specified. 

New Relations 

Since an operation producing a relation (or a group 
of relations) must create new segments to hold these 
relations, the following procedure is followed to 
handle naming: 

1. If F option is specified, the new relation is 
given the name of the one to be deleted. 

2. Otherwise, the console is queried. This policy 
is changeable if the need arises for another 
approach to this case. 
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Error Handling 

This is handled by a system program called GS_error. 
The user will receive a message of the form: 

Error xxx Internal opcode was y 
followed by two pointers, a name and pointer, or two 
names of interest (their meaning depends on the error 
code xxx) followed by an error message. Y is the 
internal code for the operation in progress and is 
indicated with each call description. Depending on 
the call form to GS_error, the user may be given the 
opportunity to return and continue from where the 
error occurred. The nature of the results will de- 
pend on the error incurred. Appendix G describes 
GS_error in greater detail. All error messages are 
stored in GS_err_messages with the k line being 
the message for error number k. 
The reader is referred to the PL/1 code listings of the 
manager which include all of the PL/1 structures used by 
the system (see Appendix F) , and to Appendix E, which con- 
tains the important PL/1 structures in an annotated form. 

The operations are classed into six groups. They are: 

1. Pure set theoretic -- those outlined in Chapter III, 
section 1. 

2. Ordered set theoretic -- those considered in Chapter 
III, section 2. 
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3. Structural utilities -- for conversion to and from 
quarts and relations, and to and from scalar quarts 
and arrays of quarts. 

4. ENT utilities -- for examination and manipulation 
of the ENT's. 

5. Token creation and maintenance -- the creation and 
examination of reference numbers in data areas. 

6. System Utilities -- for the creation, initiation 
and deletion of data areas and relations. 

Finally, the reader is referred to Appendix H which 
describes a useful debugging aid, and to Appendix I which 
contains simple examples of many of the operations per- 
formed on quarts. 
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Pure Set Theoretic Operations 

union (un=abbreviation recognized) (U=internal opcode) 

q=mgr$un(q[,{J}] [.option]) 

r=mgr$un(r[,{J}] [.option]) 
(p->)Q=mgrSun(Q[,{§}] [, option]) 
(p->)R=mgr$un(R[,{§}] [.option]) 
options : F,S 

This is the set theoretic union of the two arguments. 
A null second argument is interpreted as empty; i.e. it 
produces a copy of the first argument, 
intersect (in) (I) 

Forms as in union 

This is the set theoretic intersection of the two ar- 
guments. A null second argument produces a quart identical 
to the first except with no elements, 
difference (di) (D) 

Forms as in union 

This is the set theoretic difference of the two argu- 
ments. A null second argument produces a copy of the first 
argument . 
cart_prod (cp) (X) 

Forms as in union 

This produces the cartesian product of the two argu- 
ments. The result contains a column for every column in 
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the inputs, with a tuple for every possible concatenation 
of each of the input tuples. For example, 

ab £ ^ f*b.£^ 

1 11 21 31 1 11 21 31 

X 

2 12 22 32 1 11 22 32 

2 12 21 31 
2 12 22 32 

A null second argument produces a copy of the first, 
compose (co) (C) 

q=mgr$co(q[,{J}] [,eqp] [, option]) 

r=mgr$co(r[,{J}] [,eqp] [, option]) 

Cp->)Q=mgr$co(Q[,{£}] [ ,EQP] [, option] ) 

(p->)R=mgr$co(R[,{g}] [,EQP] [, option]) 

options: F,S 

The composition is performed in the following way: 
1. If there is an equivalence vector (pointed to by 
eqp) it must be of the form 

eqp -> width name(l) name (2) .... name (width) 

where width=sum of the orders of the inputs. 
Bindings are then made between the names in the 
equivalence vector (neq's) and the CENT'S in a 
sequential fashion. For an example, take 
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input 1 -*■ a b input 2 ■+ c d eqp -»- 4 w x y z 

then the bindings are a-w, b-x, c-y, d-3. An "§" 
(ampersand) in the equivalence vector causes a CENT 
to be bound to itself. eqp -»■ 4 w § y § above would 
produce bindings a-w, b-b, c-y, d-d. A null pointer 
for an equivalence vector has the same effect as if 
the vector were all ampersands. 

2. The resulting quart (or relation) will consist of 
one column (conceptually, in the relation's case) 
for each unique, non-blank neq. For example 

eqp -*■ 4 w x y z produces w x y_ z 
eqp -*■ 4 w x w z produces w x z_ 
eqp -*■ 4 w "" w z produces w z_ 

3. A TENT in the result is produced from a TENT from 
each of the inputs such that 

a. All input columns with identical bindings have 
an equal refno (which goes into the resulting 
column headed by the binding's name). 

b. When the above holds true, other columns from 
the result are filled from the other input 
columns bound uniquely to the result column's 
name. 

c. Columns bound to blank names are ignored. For 
example, given 
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produce the two lines Jones_33 Maple_783-8001_Ford and 
Jones_33 Maple_783- 8001_Chevy . Had there been no listing 
for Jones_33 Maple in either of the directories, the result 
would not include him. 
project (pr) (0) 

q=mgr$pr (q ,eqp [ , option] ) 

r=mgr$pr (r ,eqp [, option] ) 
(p->)Q-mgr$pr(Q,EQP[, option]) 
(p->)R=mgr$pr(R,EQP[, option]) 
options : F 

This projects out all columns whose name in the equiv- 
alence vector is blank. The width of the vector must be 
equal to the order of the input, and the values in the equiv- 
alence vector replace the original CENT'S in the result. 
For example 

a b c eqp 3 x y " " x y_ 

1 11 21 1 11 

1 11 22 yields 3 13 

3 13 23 
Note that after a column is removed, any duplications in 
TENT's are deleted to a single entry. The ampersand may 
be used to indicate that the CENT for that column is to 
be unchanged. 
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Ordered Set Theoretic Operations 
sort (so) (S) 

Forms as in union 

This sorts the first input with respect to the order 
of the ENT of the second input. Both inputs must contain 
the same ENT elements, unless the second input is null, in 
which case the first input is sorted without change in ENT 
ordering. Note that the effect of sorting according to an 
equivalence vector can be had by saying 

q=mgr$so(q' ,mgr$me(q' ,eqp)) 

where eqp points to a vector containing the ENT elements 
of q' in the desired order (see modify _ent later on). 
successor_relation (sr) (P) 

q=mgr$sr({J} [,q] [.option]) 
(p->)Q=mgr$sr({g}[,Q] [, option]) 
options. F,S 

This produces the TENT in the first argument which is 
immediately greater than (in the lexicographic sense) the 
first TENT in the second input. If the second arg is null 
or non-existent, the first TENT in the first argument is 
returned. If there is no successor, a zero-length quart 
is returned. For example, 
given first input a b c 
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Structural Utilities 
convert_to_q (cq) (Q) 

q-mgr$cq({^} [, option]) 

(p->)Q=mgr$cq({Q} [.option]) 
options : F 

The first argument is converted to a quart. 
convert_to_r (cr) (R) 

r=mgr$cr ({ J}, r[, option]) 

(p->)R=mgr$cr({^},R[, option]) 
options : F 

This converts the first input to a relation with 
respect to the RSM used for the second input. 
expand_quart (eq) (T) 

Q=mgr$eq(q) 

This converts a quart of length n into an array of n 
length 1 quarts. 
squash_array (sa) (T) 

q=mgr$sa(Q) 

This converts an array of quarts (with identical ENT's) 
into a single quart. Duplications in TENT's are not deleted, 
but the result ijs sorted. Care should be exercised not to 
allow duplications to hinder proper operation (the duplica- 
tions can be removed by projecting without removing any 
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ENT Utilities 
get_ent (ge) (E) 

eqp=mgr$ge({J>) 

EQP=mgr$ge({§}) 

This returns an equivalence vector containing the CENT 
portions of the input, 
modify ent (me) (M) 

q=mgr$me(q,eqp) 

r=mgr$me(r ,eqp) 
(p->)Q=mgr$me(Q,EQP) 
(p->)R=mgr$me(R,EQP) 

This changes the CENT portions of the input to the 
contents of the equivalence vector. The returned pointers 
are the same as the input. Ampersand ($) may be used. 
clear_ent (ce) (Z) 

q=mgr$ce(q) 

r=mgr$ce (r) 
(p->)Q=mgr$ce(Q) 
(p->)R=mgr$ce(R) 

This clears to NULL the PENT portions of the input and 
returns the input pointer. 
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Token Operations 

At this point, it is well to point out a practical 
consideration which necessitates distinguishing a CENT 
element from a data type. It is possible that one would 
desire a relation such as employee-employer; but in this 
case, the reference numbers for employees and employers 
could refer to the same data type, namely personnel or 
name . To allow for the case where two CENT entries must 
be distinct, yet refer to the same data-type (and associated 
data area), the following convention is adopted: for all 
relational operations (RSM) , the entire CENT is used; for 
all token operations (DSM) only the first four characters 
are used. Hence, we could have the relation name_employee- 
name employer with both columns refering to the same data 
type "name". 

By way of explaining the PENT, let us first note that 
when a CENT is used by a DSM to indicate a data type (by its 
first four characters) , this character name is associated 
to the data area by a pointer variable. This pointer is 
then stored in the PENT linked to the CENT in question. 
Then, in future references to the quart in question, the 
PENT's which are non-null can be used directly without 
incurring the overhead of translating the first four charac- 
ters of the CENT into a pointer to the data area. 

A final note: in discussing the following operations, 
q' will refer to the special case of an order one length 



-104- 
one quart. So, we will be talking about the CENT and the 
TENT of a singleton quart. 
get_refno (gr) (R) 

q'=mgr$gr(d,{^p}[,sptr] [,ent] [, option]) 

(p->)Q , =mgr$gr(D,{^p}[,sptr] [,ent] [, option]) 

options : D, I 

d is a pointer to a raw data item such as string or 
an integer. This operation takes a data item and returns 
a singleton quart with the item's reference number. The 
data area used is determined by its name, type , or by a 
pointer to it (which is more efficient), dp(which can be 
obtained via MULTICS hcs_$make_jptr routine or by the new_ 
data_type operation outlined in group six). The resultant 
CENT is type unless ent is specified, in which case that is 
put in. If an item is not in the data area, and I is not 
specified, a zero-length quart is produced; if I is speci- 
fied, the item is inserted, and the new reference number 
returned. With D option, the refno is returned despite the 
item's being deleted. sptr is an optional argument provided 
for certain DSM's where the user must indicate after which 
item an insertion is to be made; it is a pointer to another 
data item. 
get_data (gd) (D) 

d=mgr$gd(q[, type ] [, option]) 
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(p->)D=mgr$gd(Q[, type ] [, option]) 
options: D,E,1,2,...9 

This converts a reference number to a raw data item. 
The data area to be used is determined by type if specified; 
otherwise it is determined as indicated in the preface of 
this group from the n CENT, where n is the number option 
specified (1 is the default). Basically the number option 
permits the user to choose which column of the quart to use. 
The refno used is then the first in the n column. 

The E option permits an entire column to be operated 
upon since 

(p->)D=mgr$gd(q,"E")=mgr$gd(mgr$eq(q)) 

The E option is much more efficient, however. Finally, 
even if the D option is specified, the item is returned, 
but then deleted; references to non-existent items yield 
a result of NULL. 
successor_data (sd) (S) 

q'=mgr$sd(q [, type ] [, ent ] [, option]) 
(p->)Q'=mgr$sd(Q[, type ] [ ,ent] [, option]) 
options: D,E,1,2,...9 

The reference number and data area to be used are 
determined exactly as in get_data, using the column number 
option, and CENT conversion. Waht is returned is a single- 
ton quart (with ent for its CENT if specified, else type ) 
containing the reference number of the item which is "next" 
after the input refno. The order on the data is determined 
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by the DSM, but reference numbers are always assigned such 
that numerical order is kept by the order on the data. 
Hence, successor_data returns the next greatest refno which 
is included in the data area; the input refno need not be 
included in the data area itself. D options causes the 
deletion of the item whose successor was found, if there 
was one, not the successor itself. Finally, a null input 
or zero refno returns the first refno in the area, while 
if no successor exists (the input is greater than or equal 
to the last refno in the area), a zero-length quart is 
returned. 
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System Utilities 
initiate_relation (ir) (Z) 

r=mgr$ir (name) 

This intiates the relation " name " and clears the PENT 
portions of the relation (this is necessary since each new 
process invalidates all stored pointers by virtue of the 
new segment numbers assigned) . 
new_relation (nr) (N) 

r=mgr$nr(name,r) 

This creates a new relation by the name " name ", and 
assigns to it the same RSM as the second input. 
new_data_type (nd) (N) 

dp=mgr$nd( type , DSM ) 

This creates a new data type " type " (which must be a 
name A_ characters in length) and assigns to it the DSM 
named " DSM ". dp is a pointer to the new data area. 
kill_data_type (kd) (K) 

NULL=mgr$kd({g ype » 

This deletes the data type " type ", if that is given, 
or deletes the data type associated with the first ENT 
element of the input quart, if that is given. (See preface 
to group 5.) 
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2. Programming Considerations and Specifics 

The user is referred to Appendices E and F for the 

system structures which serve as interfaces, and for the 

code of currently existent modules. 

Special Functions of the Manager 

The manager serves to make the rigid calling sequence 
enforced by PL/1 less of a problem. In the formal 
language, it is not possible to omit arguments, or to 
have a choice of the form (pointer, string, etc.) of a 
given argument. For example, the call to kill_data_ 
type could not be handled by the standard PL/1 facili- 
ties (it takes either a pointer or string) . The mana- 
ger overcomes this problem using a utility which ob- 
tains for the program a pointer to the arguments, but 
makes no interpretation (see cu_ in Multics Manual) . 
The arguments are then treated, on a machine dependent 
basis, by code designed to test for argument types as 
well as contents. This code then permits the user to 
be free with his form and receive a diagnosis of trouble 
from GOLD STAR (rather than from MULTICS) which is more 
specific in its messages. 

The manager also serves a number of other vital needs. 
It contains all of the machine dependent code (except- 
ing area considerations, which are mentioned later). 
Segment and name-space management are handled by the 
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Arrays and Calls 

In MULTICS, the call and return sequence is relatively 
expensive, often taking the same time as fifty or more 
machine instructions. To minimize this overhead, GOLD 
STAR is designed to deal in arrays of pointers as well 
as in pointers alone. By this vehicle, the user can 
achieve the effect of iterative calls by passing instead 
whole arrays. The system routines then iterate within 
themselves, saving the need to iterate upon the calling 
sequence. Hence, the entire system is designed to 
effectively minimize the number of calls. Hence we 
find that the following two calling sequences are 
identical in effect, 
del (A,B,C) (n)pointer; 
del D (n) pointer based (x) ; 

A=mgr$un(B,C)+D; 

is the same as 

del (A,B,C) (n)pointer; 

do i=l to n; 

A(i)=mgr$un(B(i),C(i)); 

end ; 

The second is less efficient due to call overhead. 

Paging 

Care must be taken that a minimum number of pages are 

requested in a limited period of time. Otherwise, 
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excessive waiting for pages will ensue. Basically, 
only two remedies are available: limit code as much 
as possible to linear flow without external calls, 
and localize external references to a given page. 
The modular construction of GOLD STAR lends itself to 
these restrictions; most modules have approximately 
linear flow, and during a given task, usually only a 
strategy module, a data area (or relation segment), 
and the free_free segment (dynamic allocations) are 
needed. There is virtually no intercommunication 
needed among the various system components other than 
in a simple linear transfer of control. 
Frequent Trouble Spots 

One of the most troublesome errors to encounter is 
that that of passing around erroneous pointers. The 
system takes care not to permit null pointers to be 
transmitted where they are going to cause a MULTICS 
error. The user must be very careful not to use 
uninitialized or incorrectly set pointers, as they 
can cause disaster. 

GOLD STAR makes extensive use of allocations, and, in 
fact, returns all values in based allocations. The 
user should beware of filling up this free_free area; 
the system cleans up where possible, but cannot do so 
in some cases. For instance, when a pointer to an 
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array of results is returned, that array must be 

freed by the user to clean up properly (single returns 
are handled by the system) . 
Dynamic Storage 

GOLD STAR is suitable for manipulation of large aggre- 
gations of data. At any one time, however, only a 
small portion of the collection need be accessible 
to user and system programs. In addition, GOLD STAR 
utilizes a certain amount of ephemeral storage in the 
form of QUARTS. In order to reduce the amount of 
storage required at any one time the free storage 
facilities of PL/1 are frequently invoked. Thus QUARTS 
and some character strings exist only as long as a user 
deems necessary. 

In addition to those instances where ephermal data is 
used, data-reference number bindings are stored in a 
PL/1 accessible AREA. This feature, also used by 
RSM_Q, allows effective management of data which is 
dynamic in nature, without explicit storage management 
by the user. 
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/* grade list contains: "semester", "subject_number" , 

"letter_grade" , "student_name" */ 

compose_ptr=mgr$cart_prod(mgr$cart_prod( 

mgr$get_refno(F_ptr,"letter_grade") , 
mgr$get_re£no(subj_ptr,"subject_number)) , 
mgr$get_refno(term_ptr ."semester")) ; 

/* this forms an order 3 quart with the CENT'S "letter_ 
grade", " sub j ect_n umber" , and "semester" */ 

f i_ptr=mgr$compose (compose_ptr ,£i_ptr) ; 
failed_ptr=mgr$project(fi_ptr,addr (names)) ; 

/* now get addresses of the names already obtained */ 

fi_ptr=mgr$initi at e_relation("student_di rectory") ; 

fi_ptr=mgr$compose(fi_ptr,failed_ptr) ; 

call labels (£i_ptr) ; 

return; 

end; 
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AUTIIOR COMMENTARY -- L. ALAN KRANING 
ASPECTS OF THE MODEL 

The development of any large system must presume that 
certain trade-offs will be made during the implementation 
phases, but there are certain pre-implementation and pre- 
development considerations that have far more significant 
impact than the actual generation of a working system. 
First of all, the needs which motivated the design of the 
system must be considered in detail. The GOLD STAR system 
is suitable for administrative data management needs for a 
university such as M.I.T., but it is not at all obvious 
how well such a system would perform in other environments 
where the decision structure were different. Second, de- 
spite the generality of set theory, the GOLD STAR model 
presented in Chapter II reflects my biases, the biases of 
my thesis partner, and biases of those who will use the 
system about the nature of relatedness . An exact defini- 
tion of "a is related to b" is difficult to produce without 
using words as nebulous as "related". What do we mean when 
we say that "John" is related to "Dodge"? Difficulties in 
this area -- especially in determining what relations are 
and are not properly included within a data-base -- ultimately 
determine the utility of our model. 

The nature and degree of trade-offs in GOLD STAR revolve 
about some conflict between the unordered nature of sets and 
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the ordering of storage in computers. Retrieval of ele- 
ments from sets is not well specified, but since sets and 
operations on them are abstract, this is not severe. 
However, in an environment where sets must be represented 
as bit strings in a totally ordered memory, we must specify 
an algorithm for retrieval of any item, as well as speci- 
fying its representation. Large scale associative memories 
would aid in representation of sets, but current technology 
and economics of implementation now preclude such a situa- 
tion. 

The quart construction saves storage space by "fac- 
toring" the data type names out of a relation. However, 
many to one relations such as the name-friend relation 
would replicate many data elements when considered as a 
quart. While the quart imposes ordering implicitly by 
storage address , it suffers the same malady of other data 
structures: retrieval of information must somewhere take 
into account an immutable order on memory. The notions of 
dynamic storage management and pointer data elements allev- 
iate part of this burden, but only at execution time. The 
programmer must completely specify, or accept someone else's 
specification, for a mapping between sets and storage cells. 
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AUTHOR COMMENTARY -- ANDREW FILLAT 
ASPECTS OF THE IMPLEMENTATION 

There is a distinct dichotomy of feelings which accom- 
pany the birth and early life of GOLD STAR. 

On the positive side is the most important feature of 
all: the framework of the system; once truly familiar to 
a user, it is one that reduces many exceedingly difficult 
data problems to amazingly short and simple algorithms. 
It was, in fact, hard to come up with a non- trivial example 
(at least from the coding standpoint) . 

In addition, on the positive side, is the vast open 
space that GOLD STAR can expand to. As special data hand- 
ling needs arise, new strategy modules can be written to 
increase efficiency, without ever redesigning the options 
which use the system. 

The apprehensions are attributable in great part to my 
inherent skepticism. There are many nagging doubts at this 
point of how marketable the entire MULTICS system really is. 
GOLD STAR, though not designed for MULTICS alone, depends 
upon its host for many of its nicest features and conveni- 
ences. It seems a loss to create a one-of-a-kind system, 
even if it becomes an integral part of the installation. 

The issue of efficiency is also a nagging one. There 
is no way to my knowledge that one can test the design of 
a module under heavy loads until enough of the entire system 
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is available to create such a load. Hence, there is little 
way to elicit the performance of the system under production 
conditions. Although indications to date are excellent, it 
somehow sits uneasily upon me to be forced to design such a 
complex entity as GOLD STAR so empirically. 

My final and I think most serious doubt is the possible 
"understanding gap". After conceiving, creating, and devel- 
oping GOLD STAR in collaboration with the co-author, the 
system has become a perspective on my thinking. It is dis- 
turbing to realize how difficult it is for a detached but 
interested party to conceive of the system or his problem 
in light of the system. It is my hope that the systematic 
(albeit untested) approach presented through this disserta- 
tion will allow a user to become familiar with our set the- 
oretic conception of data. 

Finally, I would hope that a wide range of users would 
be willing to tackle the job of learning about GOLD STAR. 
I am convinced that the entire administration of M.I.T. 
could use GOLD STAR to handle virtually every part of its 
problems and assignments. It is my hope that these other 
people will see the tremendous value in our system. 
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APPENDIX A 
A LEMMA ON THE NESTING OF PROJECTIONS 

Lemma I. ^TtgRfx) = ir^gRCx) = Tr g 7r A R(x) 

Proof: 

if X = domUR(x) then by the definition of 
projection in (3-8) 

tt b R(x) = {f:XflB-N D | (3g)(geR(x) t, fcg)} 
Thus , 

tt a tt b R(x) = {h:An(xnB)-^N D | (3g) (geR(x) 5 h 5 g) > 
But 

An(XOB) - Xn(AflB) = Xn(BHA) 
So 

tr A Tr B R(x) = ir AnB R(x) - tt^RCx) 

Q.E.D. 
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APPENDIX B 
ALPHABETIC ORDER AND REFERENCE NUMBERS 

Data types ordered by alphabetic sequence will usually 
be large in size, typically of the order of 10 or greater. 
Many types will be highly active in numbers of insertions 
and deletions. The large size of any data type poses no 
significant barriers if the number of bits composing a 
reference number is sufficiently great; the MULTICS imple- 
mentation of GOLD STAR uses a 35 bit reference number, 

34 
which limits the size of any data type to 2 - 1 = 17.8 

billion data elements. The ability to insert and delete 
items with impunity is more problematic. Insertion of an 
item requires sparseness among reference numbers if well 
ordering is to be maintained. Furthermore, when either 
inserting or deleting an item, it is of utmost importance 
that previous string-reference number bindings remain un- 
affected. Alteration of any binding necessitates a sub- 
sequent search and modification of all relational structures 
where the binding was assumed valid; in large data bases this 
process becomes prohibitively expensive if frequently per- 
formed. 

One strategy which adequately serves the needs of dy- 
namic binding is the binary tree concept outlined in Chapter 
4. The illustration in Figure B- 1 extends the tree dis- 
cussed in Chapter 4. Inside each node above the data element 



rH «* 

a; n 



T3 

V II 

0) 

►J 



t 

T) 

r-l CM 

O H 

><— ' 

a> 



to 



V II 

> — ■ 
a> 



*3- 

I 

r— i 
rH O 

0> II 

>«— 

-5 



-122- 




rH B 
r-t O 



00 

eg 



o 
o 









CO 






Cv] 




— 6 




—*" ■<* ~_ 


rH (S 
70 r* 


H 




r-t -H 





_^00^S 




rH 




o/ 




i-l 




fN» 




O 


r— tsc 


/ 

' II 




1— 1 






o *,' 








i-VO 


o 






-*— ' © 


o 






e> 


O 
r-t 







«^J 



C 4-» T3 O rH be 

0» C cd 3 bO+J o A r< C it >s 

3Wr-« 3Hg>C0C«rl'O 
CT NHO'rtOl«0«)«H.HC 

<u4-iwuo2:t-QaoQ<3:< 
to o 




o 

r-t 

o 



II 



o 
o 



r- 

< 

4J 

ca 

Q 



l/> 

E 

c 






I 

u 

3 

tse 



-123- 

name is a bit string which, when read left to right, indi- 
cates the left and right turns required to reach an item 
in the tree. For example, to reach the root node, no turns 
are required, and to reach "Donald" turns to the left, 
right, left and right (0101) are called for. Two problems 
prevent direct usage of these "path trace" numbers as 
reference numbers. First, since all reference numbers are 
36 bits long, the "path trace" numbers 00, 0, 000, and 0000 
would be indistinguishable, as would be the set 101, 1010, 
101000000, and 10100. Second, the bit strings serving as 
path trace numbers do not preserve the well ordering among 
the data elements. For example "George" lexicographically 

precedes "Milton", yet path trace r = 10 is greater 
r ' c — George 

than path trace...,. = 1. Uniqueness of reference numbers 
v — Milton ^ 

and preservation of order will both prevail if we adopt the 
following schema: 

Assume that a word of storage identifies bit positions 
as below: 



most significant 
bit (msb) 



least 
significant 



, r +, bit (lsb) 

»i » » ■ — — ■ i i I 

fn 210 

sign bit 

Without loss of generality, we let the i bit position 
i = n-1, n-2, ...3, 2, 1 hold the flag, or 1, for 
left and right turns respectively to be taken once we 
reach the i 1 level of the tree. Note that a tree of 
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maximum depth n will require n bits for representation 
of path trace numbers. 

Assume that the first 1 bit starting from the right 
indicates that all bits to its left are significant 
in a path trace. Thus the path left-left-right- left- 
right would result in a path trace 00101 and a refer- 
ence number 

— ■+ path trace number 



sign' 



.00 loTlOOOOOOOOOOOOOOOOOOOOOOOO 00000 



-t — path trace flag 



Figure B"L shows reference numbers below each node 

both in binary and decial. Thus if a data item is 

found at depth k of a tree, its reference number can 

d . , 
be expressed as (E a.2 1 ) + 2 with a. = or 1 for 

i = k x 
i = k,k+l,...d. (2 in binary is represented as 

a 1 bit in position i, if the bits are labeled as dis- 
cussed above.) To compute a reference number from a 
string, we set i = d, and then compare the given string 
with the root datum. If equal, the reference number 
is 2 . If the given string is less than the root, the 
reference number is 0-2 1 + the reference number ob- 
tained by 1) changing the "search" node to the root's 
left descendant, and 2) reducing i by 1. An analagous 
procedure applies to the right. If the given item is 
greater than the root node, then its reference number 
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is 1-2 1 + the reference number obtained by 1) changing 
the "search" node to the right descendant, and 2) re- 
ducing i by 1. 

Notice that at each step of the search, reduction of 
the value of i will ensure ref#(a) < ref#(b) «-»- a < b. 

Overflow of the Binary Tree 

Figure B" 1 illustrates a tree structure resulting 
from one of many possible input sequences for the data type 
"names". Although the tree is not optimal, i.e., all nodes 
in which both descendants are missing lie on either level i 
or i + 1, fine bits are sufficient to contain all reference 
numbers. What happens, however , if we attempt to insert the 
item "Cyrus"? If we descend the tree searching for an in- 
sertion position, this item would logically be the left 
descendant of "Dan"; however, such an insertion cannot be 
made with a five bit reference number; hence we must restruc- 
ture the tree before inserting "Cyrus". The Ness 1 algor- 
ithm for restructuring trees to optimum depth yields the 
form in Figure B- 2. The restructuring process destroys 
the entire set of old bindings; to retain the viability of 
relations and quarts in which the original bindings parti- 
cipated, a quart is produced, relating new and old reference 
numbers for each member of the data type. At restructure 
time, the user is informed of tree overflow, and the exis- 
tence of the new-old-refno quart. He then performs composi- 
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tion of this quart with the necessary relations. The tree 
overflow problem will in practice arise very infrequently; 
however when overflow does occur, it is mandatory that 
recovery procedures by operable. 

Randomizing The Input Sequence for dsm_astring 

Referring to Figures B-l and B-2 we note that the 
particular organization of that tree depends to some extent 
upon the sequence in which data elements are entered. In 
particular, if we insert a large number of data elements 
which are input in alphabetic order, then the tree will 
quickly overflow. Alleviation of this problem is accom- 
plished by scrambling large sets of input data prior to the 
binding process. 
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APPENDIX C 
A FORMAL SYNTAX FOR A PARSER 



<Regular Expressions : : <EXP1>/<NUMERIC EXP><VARIABLE> 

<EXP1>= : : <EXP2> | <EXP2><OR><EXPl> 

<EXP2>= : : <EXP3> | <EXP3><EXP2> 

<EXP3>= : :<PEXP4> | <PEXP4>* 

<PEXP4>=: :"<literal>"| $|?|l|.|<|>| "<PEXP4>| 

(<Regular Expression>) 
<NUMERIC EXP>=: :<NUMERIC EXP1> | <NUMERIC EXPl><OR> 

<NUMERIC EXP> 
<NUMERIC EXP1>=: :<NUMERIC EXP2> | <NUMERIC EXP2><NUMERIC EXP1> 
<NUMERIC EXP2>=: :<NUMERIC EXP3> | <NUMERIC EXP3>+ | 

<NUMERIC EXP3>- 
<NUMERIC EXP3>=: Kdigit strings> 
<VARIABLE>= : : <character strings> 
definitions: <0R>e| 

$ = any digit 

? = any upper case character 

! = any lower case character 

. = anything 

< = left anchor 

> e right anchor 
Note: any special character appearing twice in succession 
is interpreted as one of itself. 
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APPENDIX D 

PROTECTION ON MULTICS 

1. The Basic Concepts 

Each segment in MULTICS possesses an access control list 
(ACL) which lists all processes which may access that segment, 
and the restrictions on that access. There also exists a com- 
mon access control list for each process (CACL) which can be 
viewed as simply an ACL common to all of a user's segments. 
The possible forms of access are read (R) , write (W) , execute 
(E) , and append (A) , or no access (this appears as a blank in 
the ACL but will be signified by either - or X) . It should be 
noted that by process, what is meant is a thread of control; 
i.e., no matter who the segments "belong to", a series of calls, 
returns, and execution represents the thread of control of a 
process. It is important to note the ACL discriminates by this 
process concept. 

As well as an REWA attribute, each process listed in the 
ACL possesses a ring bracket, of the form a:b:c. This ring 
bracket specifies the action the supervisor will take upon a 
call from this listed process depending on which ring the 
calling process is in. The general concept of rings is merely 
an extension of the two state system to 64 states; operations 
permissible (in this case, by operations we mean access and 
calls) grow progressively more restricted as we move out from 
ring to ring 63. Part 3 is a discussion of how rings work, 
and the following diagram should indicate how rings serve an 
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analogous purpose to states. 



Ring bracket listed 
in called segment 
for calling process 



Calling process o-fa-1) a-b (b + l)-c (c+l)-63 
in ring 

Effect of a call: Legal Legal Legal if Illegal 

New Ring=a Ring call is to 
Unchanged "gate" 

New Ring=b 

Effect of non- 
call access: Illegal Legal Illegal Illegal 

This is all subject to the REWA permission listed for the 
calling process. In words, the essence of this ring bracket 
is as follows: if the calling segment is in the first speci- 
fied range (a to b) , then all forms of access are legal, and 
no ring changes occur; if the calling segment is in the second 
range (b+1 to c) , only a call is permitted, and this generates 
a "gate crossing fault" (the fault is analogous to the excep- 
tion generated when a problem state program makes a call on 
the supervisor, entry to the more privileged routine must be 
at specified places, or "gates"); if the calling segment is 
in the low outside range (less than a), only a call is per- 
mitted, and an "attempt to execute data fault" is generated 
(the name is misleading as Part 3 indicates , but the 
situation is analogous to a supervisor calling a problem 
program-care must be taken to allow the less privileged called 
program only the arguments passed to it, and not to allow any 
access to the calling programs 1 more privileged data); if the 
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calling segment is in the high outside range (greater than c) , 

no access is allowed. 

This gate scheme has distinct advantages over a simple 
two state system. First, by using ring for the supervisor, 
the HCS can be fully protected from undesired access by speci- 
fying a ring bracket of 0:0 :i (i any other ring) for all pro- 
cesses. Yet, under this view, the HCS becomes merely a copy 
of code available to everyone; system processes (usually 
called daemons) can run in any ring, and still have full 
access to the HCS if its process is permitted from any ring, 
without allowing other users unrestricted access. The second 
major advantage is almost a corollary to the first; by writing 
a sub-system in ring i, any user can possess supervisor type 
privileges over his system by having his users in ring i+1. 
The logical consistency of this plan is clear: the HCS is to 
its sub-systems as the sub-system is to its users. Since each 
user can itself be a sub-system, the uniformity of this scheme 
is fantastic. The ability to assign access on a per process 
basis, combined with the refined and extended system of states 
-- the rings -- leads to a computer system which is virtually 
tailored to the sub-system writer as well as the average, 
albeit necessarily skilled, user. 

There is one major limitation upon the flexibility of the 
ring system. I shall call this the "ring uniqueness limita- 
tion". The name describes the fact that if a user has privi- 
lege to some ring, then there is no way that another process 
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with the same ring privilege can permit access to the first 
process on a subordinate basis. For example, if Jones has a 
sub-system in ring 3 (his users run in ring 4), and Smith has 
ring 3 permission, then Jones must make the all-or-nothing 
choice of whether to give Smith unrestricted access or no 
access at all. This situation is clearly one that does arise 
on any large system like MULTICS, where there would be much 
demand for equal and independent sub-system space. 

2. Eliminating The Ring Uniqueness Limitation 

Eliminating the aforementioned limitation is clearly a 
useful and advantageous goal to adopt, at least from a theo- 
retical aspect. What would result would be a totally control- 
lable environment of sharing, where the level of privacy could 
range from zero to total. There is, however, a serious ques- 
tion of whether any scheme could both remove the restriction 
and not cost dearly in overhead. 

Three different schemes art presented which, through 
different approaches, would eliminate the MULTICS restriction. 
These ideas are the creation of non-concentric rings, the use 
of procedure as well as process access control, and the effect- 
ing of a trap mode of access. It is not possible for the 
author to make detailed analysis of the implementations or the 
overheads, for simple lack of facts; however, general assess- 
ments based on a knowledge of the system overview and the ring 
system will be made. 



-133- 
A. Non- concentric Rings 

The idea of non-concentric rings is a reasonably simple 

conceptual extension of the current ring system. A diagramatic 

presentation would be the best introduction. 
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The non-concentric rings (NCR's) would effectively define what 
might be called a "sub-system context". The advantageous fea- 
ture of this system would be that a user might have ring 3 
permission in his own sub-system context, and have only ring 5 
permission in another such context. The NCR's would isolate 
sub-systems into their own branch of the tree, and would even 
define independent scopes of authority on the higher level 
rings. The NCR's permit allotment of sufficient privilege 
without the allocation of over-sufficient permission. 

A major problem would certainly be the excessive space 
required to store information about ring status. In its full 
extension, NCR's would have a theoretically infinite number 
of subrings at every level. A practical solution, which is 
not especially costly in a theoretical sense, is to have a 
binary tree structure for the ring system. There would be 
one ring 0, two ring l's, four ring 2's, and so on. Under 
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th is plan, a process' place on the ring tree could be deter- 
mined using n+1 bits, where n is the number of levels in the 
tree (the one extra bit would be used as a flag to mark the 
end of significance in the left to right scan of the binary 
bit string). The following diagram indicates the binary for- 
mat employed. Note that the binary method places a restriction 
on the operations staff: sub-systems must be placed on a low 
enough level to permit space enough for all the co-equal systems 
In practice, ring 6, 7, or 8 would be the likely location for 
the average sub-system (thus permitting 64, 128, or 256 sub- 
systems) . 

Tree Structure of Rings 

Ring level 11000 



Ring level 1 11100 1A 10100 IB 





? ing , n 111100. . .'2 AA~ "110100. . .2AB 101100... 2BA 100100 2BB 

level 2 

There is another major problem involved with the use of 
the NCR's. That is, how do we determine faults? Clearly, 
there are two types of faults (disregarding the distinction 
between upward and downward): the standard type --as from 
2AA to 1A -- and a tree-crossing fault --as from 2AA to IB, 
the dotted line. The standard upward and downward faults are 
easily determined by being on connected branches -- simple up 
or down movement on the tree -- and would be handled exactly 
as in MULTICS. The tree- crossing fault presents a problem: 
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if we allow faulted access to gates across the tree, we run 
into tremendous problems specifying what corresponds to a 
ring bracket. A variable length list would be needed for each 
entry in the ACL specifying from which branches of the tree a 
process could call from. Another problem: how does the system 
distinguish between the faults? 

A possible solution to these problems might be to not 
allow cross-tree access at all. Then, the system could search 
for rings by simply following the branches of the tree. A 
cross-tree access would be detected if the system has to change 
direction in its tree search; i.e., if the tree search required 
going up and then down branches. Ring brackets would remain 
unchanged, and would only refer to the branches of the tree 
reachable without a cross-tree fault arising. For example, 
a segment would be specified with brackets like 1A:2:3; this 
would permit access unrestricted from 1A,2AA, and 2AB , and 
faulted access from rings 3AAA, 3AAB, 3ABA, and 3ABB. 

But note that this solution requires one important addi- 
tion to the features allowed a process: a process would have 
to be able to change its current ring so as to be able to 
reach all rings to which it is permitted. That is, a user 
with ring 1A permission who wishes to use a system in ring IB 
must be able to change his ring to the 2BA he has been per- 
mitted to by the IB system writer. This ring changing facility 
would require changes to the supervisor which would maintain 
a list of permissible rings for each process (currently, this 



-136- 

list has only one entry). Facility for users to grant appro- 
priate permissions would also have to be added, with appro- 
priate safeguards, such as another list for acceptable ranges 
into which permission might be granted. 

The system of non- concentric rings is conceptually the 
most rigorous solution to the ring uniqueness limitation of 
MULTICS. In its ideal form, with cross-tree faults being 
treated analogously to regular faults by use of an expanded 
ACL, the system should be easy to use, albeit difficult to 
implement. In the modified form, with cross- tree reference 
allowed only by a conscious change of rings, use would be more 
complicated, but implementation possibly easier. In any form, 
this system would be difficult to implement, and might not 
prove the best way to overcome the restriction of ring unique- 
ness despite its conceptual advantage. 

B. Procedure and Process Oriented Access Control 

The principle involved with this method of overcoming the 
ring uniqueness limitation is a very simple one. As well as 
specifying what processes may access a given segment, a user 
could also specify from what procedures (segments) these pro- 
cesses could issue the calls. A sample version of the current 
and extended ACL's might show how such a specification would 
appear . 

Current Form 

Mul tics. Jones.* RE 1:1:8 
Admin. Smith REWA 1:6:63 
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Extended Form 

Multics .Jones. * System. Andy RE 1:1:8 
Admin. Smith Exec* REWA 1:6:63 

What this form of extension does is to specify from what 
procedure a process must make a call to be permitted. In 
the example, only if Smith of the Admin project were calling 
from a segment named Exec. something would he be allowed 
access . 

The above scheme does circumvent the ring uniqueness 
restriction by allowing a sub-system writer to specify that 
his segments are callable only by other segments of his sys- 
tem. This would then prohibit other users, even those with 
high enough ring permission, from accessing critical segments 
on their own. As long as the dispatching segments which 
could be referred to by outside programs were permitted only 
to execute (and not to be modified), the integrity of the 
calling sequences could be maintained. 

There clearly are limitations on this type of system. 
Space would certainly prove some sort of factor where it was 
necessary to specify complex lists of permitted callers. 
Some degree of overhead would certainly be introduced in 
checking the validity of the calling procedure. This method 
would go to pot if write permission were involved at any 
level. But a more fundamental problem might be the mainte- 
nance of the integrity of pathnames. Although pathnames are 
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unique, there seems to be no assurance that a clever pro- 
grammer could not pass to a called program an erroneous 
pathname. If the system were to completely handle identi- 
fication of calling procedures, the overhead involved in 
verification might prove unworkable. 

Though this plan has merit as a conceptually simple 
one, it would be a hard plan to carry out effectively. Safe- 
guards would be required against tampering with name conven- 
tions, and proper permission specifications by users would 
become more crucial and difficult to keep track of. This 
scheme might, however, be the easiest to implement, at least 
relative to others. 

C. Trap Mode 

From an efficiency of operation standpoint, the effect- 
ing of a trap mode of access would be the best solution to 
the ring uniqueness problem. A specification of trap mode 
for a calling process would automatically invoke a trap pro- 
cessing program upon issuance of a call. This trap processor 
could do anything, including freeing the caller from future 
traps on the same segment. In the case of ring uniqueness, 
a sub-system writer could assure that the caller was in a 
properly low ring by specifying trap for all calls from 
rings too high Clow in number). The advantage of this method 
is obvious: special action is taken only on invalid refer- 
ence attempts; valid access will generate a zero overhead. 
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The problems in implementation are considerable. They 
would include such items as maintaining the integrity of the 
trap procedure itself (note that if the trap procedure is run 
under the calling process, the caller has permission to exe- 
cute, and might find it useful to run the trap procedure 
independent of any real trap) . Disabling the trap for a 
fixed period might also be difficult to accomplish without 
loss of efficiency. In fact, though the original plans for 
MULTICS included provisions for a trap mode of access, com- 
plications in the design forced its exclusion from the cur- 
rent system. 

A proposal for the inclusion of trap mode is outlined 
below. To the author's knowledge, this plan is feasible, 
although shortcomings in the interprocess communication 
facility would make a completely tight, safe system difficult. 
This shortcoming will be mentioned and considered later. A 
diagram would illustrate the basic operation of the system. 
The name appearing above each segment indicates its owner. 
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mine who had desired its activation. Argument passing 
presents a related difficulty to the system. 

The only possible solution under the current system 
design is to employ an array of "mailboxes". These would 
be segments possessed by the trap daemon, and allowed on a 
one per user basis to other processes. The daemon could 
then determine who had issued the IPC by checking the mail- 
boxes; he could be assured that the proper process has issued 
the request because only one process is permitted per mail- 
box. The two potential difficulties that arise are space 
requirements, and the possible confusion of sequence brought 
about by the asynchronous nature of the IPC requests. 

An implementation of trap mode, though not allowing as 
complete a flexibility as would non- concentric rings, would 
certainly provide that extra leaway of freedom to expand 
upon the available sub-system capabilities. The ring 
uniqueness limitation would be eliminated in an indirect 
way. Those programs which require special screening due 
to ring permission would experience considerable overhead, 
but those permitted only to low rings (high in number) 
would be unaffected by the safeguards imposed through trap 
mode. Trap mode is certainly not an easy concept to imple- 
ment, but it might well prove a worthwhile investment in 
time and effort. 

Eliminating the single big restriction of the MULTICS 
protection method is to be a virtual necessity as the size 
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and applicability of the system increases, and more sub- 
systems come under its purview. Which of the three methods 
outlined is taken, or whether another method is used is not 
so crucial. It is most likely that overheads, and not theo- 
retical advantage, will determine the final choice. It is 
hard to divorce oneself from the idea that a free sharing 
environment is the ideal, given the ability to totally 
regulate its scope. It is this idea of a full range -- from 
total privacy to total sharing -- that must be the ultimate 
goal of protection design. 

Just as generalization brings flexibility, it also 
brings overheads and time consumed where the activity might 
have been foregone. It is the ultimate futures of MULTICS- 
like systems which will bring at least a statistical answer 
to the trade-off at hand. 

3. How Rings are Implemented in MULTICS 

Associated with each process is a set of descriptor 
segments, one for each ring in which the process has access 
defined in the ACL by ring brackets. A schematic represen- 
tation would prove useful: (x=no access; i=any ring of 
higher number) 

Segment name DS DS 1 DS 2 DS 3 DS 4 . . . DS I Bracket 

in ACL 

aaaa 
bbbb 

cccc 



R 


RE 


X 


X 


X 


l:l:i 


R 


R 


RE 


X 


X 


2:2:i 


R 


RE 


RE 


RE 


X 


l:3:i 
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The ring of current execution is determined by which des- 
criptor segment (DS) the descriptor base register points 
to. The following enumeration of cases describes how the 
file system uses rings. 

A. cccc calls or refers to bbbb ; current ring is 2 

All attempts at access are legal, as governed by the 
RE permission. 

B. bbbb calls aaaa; current ring is 2 

1. no access is found in the ring 2 DS; a gate crossing 
fault causes the gatekeeper to obtain control (the 
gatekeeper is conceptually an independent overlord) 

2. gatekeeper examines DS 0-1 for E access in aaaa 

3. if access is found, first ring in (highest number) 
is used; third element of bracket is checked to 
assure call is from a valid ring 

4. referenced entry point is validated as a gate 

5. if all is OK, DBR is loaded to point to DS 1 

C. bbbb refers to aaaa; current ring is 2 

Non-call references are illegal; the effect is the 
same as accessing another segment with no permission 
at all. 

D. aaaa refers to bbbb; current ring is 1 

Read is permitted; WA is permitted only if the ring 
bracket of bbbb includes the current ring in the 
first range (a:b) . 
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E. aaaa calls bbbb; current ring is 1 

1. since there is read permission, an attempt to 
execute data fault is generated, and the gatekeeper 
takes control 

2. gatekeeper checks DS 2-63 for E access 

3. first ring down with E is used; no gate is checked 
for 

4. DBR is reloaded to DS 2; appropriate arguments are 
made available to the lower ring bbbb 

There is one safeguard worth noting. The system will 
not allow a ring bracket to be assigned to any segment such 
that any element of the bracket specifies a ring lower in 
number than the ring it is being created from (the current 
ring). Thus, a user in ring 2 cannot assign 1:1:3. This 
guards against a user writing a lower number ring routine, 
and then transferring to it, thereby giving him higher 
level privilege than he should have. 

One other note: a called segment will run in the same 
ring as the caller is in, unless a fault is generated; in 
that latter case, the new ring will be the nearest ring 
numerically to the calling ring. 
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APPENDIX E 

SYSTEM INTERFACES 

1. User to System Interface 

The option writer or user of GOLD STAR needs basically 
the PL/1 environment and temporary storage facilities, and 
a collection of segments which he wishes to use with the 
system, and which were created by it. He need have no knowl- 
edge of the segments except their names, and the data types 
they contain if they are relations. In the case of DSM's, 
the segment name is_ the data- type. With RSM's, it is suggested 
that the segment name reflect the data-types related (e.g., 
the relation segment "name_addr" should relate data types 
"name" and "addr". 

The user deals with GOLD STAR exclusively with pointers, 
segment names, and strings (see section V-l). There is a 
very small group of items to which these pointers refer: 
quarts, relations, equivalence vectors, "data", and data areas. 
The structures are described as follows: 
declare 1 quart based (quart_ptr) 
2 ID fixed binary (35) initial (0), 
2 length fixed binary (35) , 
2 order fixed binary (35) , 

2 CENT (allocation_order refer (order) character (32) , 
2 PENT (allocation_order refer (order) pointer, 
2 TENT (allocation length refer (length), 
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allocation_order refer (order)) fixed binary (35) ; 

declare 1 equivalence_vector based (equiv_ptr) , 

2 width fixed binary (35) , 

2 element (allocation_width refer (width)) character (32) ; 

declare 1 data_item based (data_ptr) , 

2 length fixed binary (35) , 

2 string character (allocation_length refer (length)); 

Note that the data item definition is merely a way of describing 

a based varying character string. The relations and data areas 

are PL/1 areas with the first allocation containing as its 

first item the character (16) RSM or DSM name respectively. 

All other names and character strings are assumed to be 

fixed strings of whatever length is called for, if any. 

2. Internal Interface 

The manager translates the rather free form of arguments 
it receives into one of two structures for RSM's and DSM's. 
These argument structures are the sole communication between 
the system modules. 

The following is an annotated version of the PL/1 struc- 
tures used: 

declare 1 dsm_arguments based (arg_jptr) , 

2 upperbound fixed bin(17), This tells how many ele- 
ments were in input arrays 
2 column_index fixed bin(17), This is the 1, 2, ... 9 

option 
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2 operation_code character (1) , This tells which oper- 
ation is to be performed 

2 d_or_i_option character (1) , This contains either 

"D" or "I" if called for 

2 e_option character (1) , This contains "E" if called 

for 

2 data_area_ptr pointer, This is filled in by the 

manager from the appro- 
priate given information 
(CENT, PENT, or given 
name) 

2 data_or_quart_ptr (limit refer (upper_bound) ) 

pointer, These are the first arguments 

2 return_ptr (limit refer (upper_bound) ) pointer, 

These are for the re- 
sults. If sptr's were 
provided in a get_refno 
operation, they are put 
in here. 

declare 1 rsm_arguments based (arg_ptr) 

2 upper_bound fixed bin(35), This gives the upper_ 

bound of the input arrays 

2 operation_code character (1) , This tells the opera- 
tion to be performed 

2 quart l_ptr (limit refer (upper_bound) ) pointer, 
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2 relation_ljptr (limit refer (upper_bound) ) pointer, 
2 quart_2_ptr (limit refer (upper__bound) ) pointer, 
2 relation_2_ptr (limit refer (upper_bound) ) pointer, 

These are the inputs. 
The manager determines 
whether they are quarts 
or relations and places 
their pointer in the 
appropriate slot. Non- 
existent arguments are 
null. 
2 equivalence_vector (limit refer (upper_bound) ) 
pointer, These are the equivalence vectors for com- 
pose. Other operations 
needing eqv place the 
pointer in quart 2_ptr. 
2 return_ptr (limit refer (upper_bound)) pointer, 

These are for the 
results. They are null 
if the result is to be 
a quart, or point to a 
new segment of a rela- 
tion is to result. It 
is the responsibility 
of the RSM to initialize 
the new segment properly. 
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APPENDIX F 
CURRENT SYSTEM CODE 

Preface 

The following modules are included in PL/1 source form: 

mgr_declare -- these are the declarations for the manager 
mro -- this is the portion of the manager which handles calls 

to union, intersect, difference, compose, project, cart_ 

prod, sort, successor_rel , convert_to_r , convert_to_q, 

modify_ent, get_ent, and clear_ent. 
oro -- this is the portion of the manager which handles calls 

to new_relation, initiate_relation, and squash_array . 
ero -- this is the portion of the manager which handles calls 

to expand_quart. 
mdo -- this is the portion of the manager which handles calls 

to get_refno, get_data, and successor_data. 
odo -- this is the portion of the manager which handles calls 

to new_data_type and kill_data_type. 
GS_error -- the error handler (see Appendix G) . 
GS_err_messages -- the error messages (see Appendix G) . 
gsdb -- the system utility program (see Appendix H) . 
dsm_astring -- this is the DSM which handles alphabetic 

strings to be placed in alphabetic order (see Appendix B). 
dsm_integer -- this is the DSM for integers. 
dsm_chain -- this is the DSM for alphabetic strings to be 

placed in a non-alphabetic order. 
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dsm_table -- this is the DSM for alphabetic strings which 
are not in alphabetic order, and which are involved 
in frequent retrieval, and infrequent updating. 

rsm wq -- this is the RSM which performs all operations 
(except, of course, convert_to_r) on two quarts. 

rsm_q -- this is the RSM which handles quarts to be kept 
permanently. RSM_Q calls RSM_WQ to operate on the 
quarts, and only handles storage and retrieval of 
quarts to and from auxiliary segments. 

tree -- this is the algorithm to restructure a tree of a 

dsm astring data area. TREE produces an optimal tree, 
and a quart of new and old reference numbers to use to 
update all relations using that data type. 
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mgr_declare. Incl .pi 1 05/20/70 



declare 1 parameter_structure based (param_ptr) / 
2 arg_no bi t(17) , 
2 filler bit(2), 
2 display_if_8 bit(17), 
2 desc_no bit (17), 
2 multlcs_junk bi t < 19 ), 

2 a_ptrs (100) pointer; /*pointers are compute 
d by formula*/ 

/♦The following is the technically correct version of the pa 
rameter structure. 

Note that the display pointer exists only if the d i 8 half 
word is 8. The actual 

method used is to compute an offset to use, since this is 
faster than this 

adjustable structure method. 

declare 1 arg_structure based, 
2 arg_no bit (17), 
2 filler bit(2), 

2 dI8 bit(lU), use of bit Ik has effect of 
dividing by 8 

2 filler bit(3), 
2 desc_no bit (17), 
2 filler b!t(19), 
2 arg_ptrs (arg_no) pointer, 
2 display_ptr (dI8) pointer, 
2 desc_ptrs (desc_no) pointer; 
*/ 
declare 1 descriptor_structure based (desc_ptr), 
2 dt_code bit (15) , /*data type code - see 
MULTICS implementation of PL/1*/ 

2 other_stuff bit(3), /*not used*/ 
2 string_size bit (18), 
2 low_bound fixed bin (35) , 
2 top_bound fixed bin (35); 
declare 1 quart based (gen_purpose_ptr ), 

2 ID fixed bin(35) initial(O), /*zero ID mea 
ns quart*/ 

2 qlength fixed bin(35), /*not used here*/ 
2 order fixed bin(35), /*not used here*/ 
2 cent(al loc_order refer (order)) char(32) , 
2 pent (al loc_order refer (order)) pointer, 

2 tent(a11oc length refer (qlength), al loc_orde 
r refer (order)) fixed bin(35); 
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declare 1 arg_array_rsm based (arg_ptr), 
2 upper_bound fixed bin(35) , 
2 opcode character. Gl), 

2 ql_ptr (limit refer (upper_bound ) ) pointer, 
2 rl_ptr (limit refer (upper_bound ) ) pointer, 
2 q2_ptr (limit refer (upper_bound ) ) pointer, 
2 r2_ptr (limit refer (upper_bound) ) pointer, 
2 equiv_ptr (limit refer (upper_bound) ) pointe 

r, 

2 return_arg (limit refer (upper_bound) ) point 

er; 

declare 1 arg_array_dsm based (arg_ptr), 
2 high_bound fixed bin(17), 
2 column_index fixed bin(17) inltial(l), 
2 opcode character(l), 
2 d_or_t_opt ion character ( 1), 
2 e_option character ( 1), 
2 data_data_ptr pointer, 
2 d_or_q_ptr(l imi t refer (hi gh_bound) ) pointer 

2 return_arg (limit refer (hi gh_bound) ) pointe 
r; 

declare fixed_plate fixed bin(35) based (gen_purp 
ose_ptr); /*fixed bin template for quart. ID*/ 

declare oset bi t ( 18 ) based (gen_purpose_ptr ); /*Th 
is is for the area manipulation*/ 

declare label_plate char(16) based (sen_purpose_p 
tr); /*this is char(16) template for ID slot*/ 

declare return_structure (limit) pointer based (r 
eturnable_ptr); /*returned to the caller*/ 

declare option character (oplength) based (op_ptr 

); 

declare based_nam character (h) based (gen_purpos 
e_ptr ); 

declare rel_name character (lentty) based (gen_pu 
rpose_ptr ); 

declare based_arg character (as_l en ) based (gen_pur 
pose_ptr ); 

declare p pointer based (n;en_purpose_ptr ) ; 

declare indexor (kk) pointer based (gen_purpose_p 
tr); /*this acheives the kk th pointer*/ 



declare callname char(16) aligned; 

declare nam character (U ) aligned; 

declare options character (3) aligned; 

declare ent character (32) aligned; 

declare op character(l) aligned; 

declare wdir character( 168) aligned; 
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declare uni que_chars_ entry external returns (char 
acter (15)); 

declare (error_table_$noarg,error_tabl e_$segknown, 
error_tabl e_$name_not_found ) 

fixed bln(17) external; 

declare (xfer,other_ptr,arg_ptr / desc_ptr,gen_purpo 
se_ptr / op_ptr / param_ptr, returnable_ptr ) pointer; 

declare access_code fixed binary(5) ini ti al ( 01011b 

); 

declare (kk, k? k^ j j # mm, i i i , 1 ini t,dl en, op length, dose 
t,1wdir) fixed bin(17); 

declare ( lerttty,err_code,new_pl ace,al loc_order / al 1 
oc_length) fixed bin (17); 

decl are ( two_arg_sw / three_arg_sw,arg_array_sw / ski p 
_3_sw) fixed bind) initial (Ob); 

decl are (opt ion_sw / nam_sw / ent_sw, ptr_sw, squash_sw, 
F_sw, S_sw) fixed bind) initial (Ob); 

declare (as_len,op_bump) fixed bin(17); 
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:iro: in ocfvlii r r- i I'lm n^dfiintcr); 
^Include mgr_decl are; 

un :union:entry returns(po!nter ); 

op-"U"; 

go to setupl; 
in : i ntersect : entry returns(poi nter ) ; 

op="l"; 

go to setupl; 
di :di f ference: entry returns(poi nter ) ; 

op="D"; 

go to setupl; 
<:p:c>rt prod: fntry rv turn-. ( i>oi nt <»r ) ; 

n|)-"X"; 

go to setupl; 
so:sort: entry returns (po! nter ); 

op="3"; 

go to setupl; 
sr :successor_rel : entry returns(poi nter ); 

op-"P"; 

go to setupl; 
cr :convert_to_r : entry returns(pointer ); 

op="R"; 

go to setupl; 
cq:convert_to_q : entry returns(pointer ) ; 

op-"Q"; 

go to setupl; 
corcompose: entry returns (po! nter ) ; 

op= , 'C"; 

go to setupl; 
me :mod i f y_ent : entry returns (pol nter ) ; 

op="M"; 

go to setupl; 
ie:get_ent: entry returns (poi nter ); 

op="E"; 

go to setupl; 
ce:clear_ent : entry returns(pointer ); 

op="Z"; 

go to setupl; 
prtproject: entry returns(po?nter ); 

op-"0"; 

go to setupl; 
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setupl: /*Here we do argument processing*/ 
ca 1 1 cu_$arr._J i s t_pt r ( pnr.im pt r ) ; 
if rt i spl ay_i f_8=S then Mosot ».ir«._no* 1 * 
else doset=arg_no; 
if arg_no<2 then call GS_error$p(12,op / nul 1 ,nul 1 ); 

/•Error here is a null argument call in*/ 

if a_ptrs( 1+doset )->dt_code=29 then do; 

/*We have first arg is array of pointers*/ 
arg_array_sw=lb; 

1 imi t=a_ptrs ( 1+doset )-> top_bound; 
if a_ptrs( 1+doset )-> low_bound"=l then call GS_ 
error$p(li*,op,a_ptrs(l),nul 1 ); "~ 

/♦Error here is non one lower bound*/ 
end; 

else if a_ptrs(l+doset )->dt_code=13 then do; 
arg_array_sw=Ob; 
1 imi t = l; 
end; 

else call GS_error$p( 13,op,nul 1 ,nul 1 ); 
/♦Error here is failure to have pointer or array of pointers 

for first arguments*/ 



op_bump=a_ptrs (arg_no-l+ ioset )->dt_code; 
if op_bump=520 |op_bump=522 then do; 

cal 1 cu_$arg_ptr (arg_no-l,op_ptr,op1 ength,err_ 
code); 

If index(optIon / "F ,, )- , »0|!ndex(option,"f ,, )- , =0 t 
hen F_sw*lb; 

if lndex(optlon, ,, S">--0| i ndex(opt ion, "s n )^=0 t 
hen S_sw=lb; 

op_bump=l; 
end; 

else op_bumo=0; 
if op="C M then kik=0; 
else ktk=l; 

if arg_no-l-op_bump>3-ki k then call (;S_er rorSp ( 15, 
op,a_ptrs( 1)- ;p,nul 1 ); 
/♦Error hero is too many arguments^/ 

do k i k = 2 to ar";_no-l-op_bump; 
i f 1 imi t = l then do; 

if a_ptrs(kik+doset )->dt_code"=13 then cal 
1 GS_error$p(16,op,a_ptrs (l)->p, 

a_ptrs(2)->p); 
/♦Error here is inconsistant upper bounds/ 
end; 
else do; 

other_ptr=a_ptrs (kik+doset); 
if other_ptr->dt_code"'=29 then call GS_err 
*or$p(17,op,a_ptrs(l)->p,nul 1 ); 
/♦Error here is inconsistant upper bound or type^/ 
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else if other_ptr->top_bound~'=l imi t then c 
all GS_error$p( 18, op, 

a_ptrs(l)->p,a_ptrs(ki k)->p); 
/*Error here is inconsistant upper bound*/ 

else if other_ptr->low_bound~'=l then call 
GS_er ror$p( l^op, a_ptrs ( l)->p,nul 1 ); 
/♦Error here is non one lower bound*/ 
end; 

if kik = 2 then two_arg_sw=lb; 
else three_arg_sw=lb; 
end; 



/*Here we compare argument structures with those permiss 
ible by operation*/ 

if two_arg_sw & (op="Q M | op="E" | op="Z") then call 
GS_error$p( 19,op,a_ptrs (l)->p,nul 1 >; 
/♦Error here is two arguments with cq,ge, or ce*/ 

if ^two_arg_sw & (op="M" | op="0" | op="R" ) then call 
GS_error$p(20,op,a_ptrs(l)->p / nul 1 ); 
/♦Error here is omission of mandatory second arg in cr or me 

*/ 

if F_sw & (op = ,, E ,, |op = "M"|op = "Z") then F_sw = 0b; 

if S_sw & (op = "Q"|op = "R ,I |op = ,, E"|op = ,, M"|op = "Z"|op = M 
0") then S_sw=0b; 



/*Here allocate argument array structure and go to work* 
/ 

allocate arg_array_rsm; 

setup2: do kk=l to limit; 

if op="C M then do; 

if three_arg_sw then arg_array_rsm.equi v_p 
tr(kk)= 

a_ptrs (3)->indexor(kk); 
el se arg_array_rsm.equi v_ptr (kk )=nul 1 ; 
end; 
if ~'two_arg_sw|a_ptrs (2 )-> indexor (kk )=nul 1 the 

arg_array_rsm.q2_ptr (kk), ars_array_rsm. r2_ 

if op="R" then go to err_20; 
end; 

else if a_ptrs(2)->indexor(kk)->f ixed_plate=0| 
op»"M ,l |op-"0" then do; 

arg_array_rsm.q2_ptr (kk)=a_ptrs ( 2 )-> indexo 
r(kk); 

arg_array_rsm. r2_ptr (kk)=nul 1 ; 
if op^'R" then do; 
err_20: free arg_array_rsm; 

cal 1 GS_error$p(20,op,a_ptrs( l)->p,a_p 
t r b ( 2 > - M> ) ; 



n do; 
ptr(kk)=nul 1 ; 
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end; 

end; 

e 1 se do; 

arg_array_rsm. r2_ptr (kk )=a_ptrs ( 2 )-> i ndexo 

r(kk); 

ar%_ar ray_rsm. q2_pt r ( kk ) =nu 1 1 ; 

if op = "P" then do;/*Error hand 1 i ng$ $$ */ 

free arg_ar ray__rsm; 

cal 1 GS_error$p( 21,op,a_ptrs ( 1 )-> index 

or(kk),r2_ptr(kk)); 

end; 

/♦Error here is attempt to get successor of a relation*/ 

end; 



/*First operand is examined here*/ 

if a_ptrs(l)-> indexor (kk )=nul 1 then do;/*Error 
handl i ng$$$*/ 

free arg_array_rsm; 
cal 1 GS_error$p(22,op,nu1 1 ,nul 1 ); 
end; 
/*Error here is a null first operand*/ 

if a_ptrs ( l)-> indexor (kk )->fi xed_pl ate"' = then 
do; 

arg_array_rsm.ql_ptr (kk )=nul 1 ; 
arg_array_rsm. r l_pt r (kk )=a_ptrs ( 1 )-> i ndexo 
r(kk); 

end; 

el se do; 

arg_array_rsm.ql_ptr (kk)=a_ptrs( l)-> i ndexo 



r(kk); 



arg_array_rsm. r l_ptr (kk )=nul 1 ; 



end; 



end ; 



/♦Here wo process calling name for most operations*/ 
snt.up'> : do kk- 1 to limit; 

if op = "R" then go to mus t_'->e_second ; 

if arg_array_rsm. rl_ptr (kk )"' = nul 1 then do; 

if kk=l then cal 1 name=addre 1 (a_ptrs ( 1 )->o, 
a_ptrs (l)->p->oset)->label_plate; 

else if addrel (a_ptrs ( l)-> i ndexor (kk ) ,a_pt 
rs(l)->indexor(kk)->oset )-> 1 abel_pl ate~" = 

cal 1 name then do ; 
/*Error handl i ng$$$ */ 
free arg_array_rsm; 

cal 1 GS_error$p(23,op / a_ptrs( l)->p / a_D 
trs(l)->indexor(kk)); 

end; 
/*Error here is specification of inconsistant RSM names*/ 
end; 
else do - 
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if -two_arg_sw|arg_array_rsm. r2_ptr (kk)=nu 

11 |op="M"|op="0" then do; 

if kk=l then cal 1 name="rsm_wq"; 
else if cal 1 name" , = "rsm_wq" then do; 
free arg_array_rsm; 
cal 1 GS_error$p(2^ / op / a_ptrs(l)->P 
, a_ptrs (l)->indexor(kk)); 

end; 
/♦Error here is inconsistant RSM names*/ 

end ; 
else must_he_second :do; 

if kk=l then cal 1 name=addrel (a_pt rs ( 2 ) 
->p / a_ptrs(2)->p->oset )->l abel_pl ate; 

else if addrel (a_ptrs(2 )->indexor (kk), 
a_ptrs(2 )-> indexor (kk)->oset )-> label _pl at e"" = 

cal lname then do; 
/♦Error handl i ng$$$ */ 
free ar^_array_rsm; 
cal 1 GS_error$p(25,op,a_ptrs(2)->p 
/ a_ptrs (2)->indexor(kk)); 

end; 
/♦Error here is inconsistant RSM names*/ 

end; 
end; 
end; 



/♦Where it is proper, space is obtained for the new resu 
It relation*/ 

setup6: if op="Q M | op="E" I op="M" | op="Z" then go to setup7; 
Ho kk=l to limit; 

ar»_array_rsm. return_arg(kk )=nul 1 ; 
if arg_array_rsm. rl_ptr (kk)=nul l v then go to no 
_new_r; *•»-«■'*- 

cal 1 hcs_$f s_search_get_wdi r (addr (wdi r ), lwdi r ) 

cal 1 hcs_$make_seg(wdi r , "", '"*, access_code / arg_ 
array_rsm. return_arg( kk),err_code ) ; 

if err_code>0 then do;/*Error handl ing$$$ ♦/ 
free arg_array_rsm; 

cal 1 GS_error$p(26,op,a_ptrsl l)-> indexor (k 
k),a_ptrs( 2)->indexor(kk)); 

end; 
/♦Error here is failure of make seg procedure*/ 

if F_sw & op-» M R" then do; 

F_sw=0b; 

opt ion_sw=lb; 

go to no_name_needed; 
end; 
else do; 

call ioa_$nnl ("Mew relation created. Op is 
"la. Relation 1 is "p. Give new name...", 



♦too c ptrsf : ) 
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i c -ir''_srrny_rs^.o?_ptr( kk)" , =nul 1 t"°n 
i ■•'- xr>r( k k) - >qu? r f ; 
<-■• 1 - '-• f : -' > I 1 hrs^fV lr-nf rv s r ^ ( 3 p c r s ( 2 ^ - > 



n ^ ^ x o r 



r n - ; 



;( t) 






i";;'i, r^ 



r: r "• ( H n i t ) ; 



yr r a y_ 



.- _ -■ ■ t -" s ( a r ■- n);->i-x' r- r ; 

T'tu r in ; 
"n-'; 

n 1 lor ~ t" n r < A t. : i r n_s t r u c t : j r e ; 
Hn ■, ; -i - 1 i-M t; 

re t j r -i _s tr;i c tu re ( ~i^ ) =a r "_ri rr.">y_rsi, r"turn_ 

r- n ■' ! ; 

f r -■ r ,~ - -__ ,ur ,i y_ r s '^ ; 

;]_;Urs(jr * _n-i ) - N r> = rp t u r nab 1 o_^ t r ; 

erv J ; 
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oro: procedure returns (po i nter ) ; 

% include mgr_decl are ; 

nr :new_relation : entry returns ( poi nter ) ; 

call cu_ <; ;arg_ptr(l / gen_purpose_ptr / lentty / err_code 

) ; 

if err_code>0 then call RS_er ror$p( 1, "N",nul 1 ,nul 1 

); 

/*Error here is null relation name*/ 

cal 1 cu_$arg_l i st_pt r ( param_pt r ); 

if di splay_if_8=8 then dnset=arg_no+ 1; 

else doset=arg_no; 

if arg_no" , = 3 then call GS_er ror$p( 2, "N",nul 1 , nul 1 ) 

/•Error here is incorrect argument specification for nr*/ 

if a_ptrs(2+doset)->dt_code^=13 then call 0S_error 
$p(3, "N" # nul l,nul 1 ); 
/♦Error here Is non_pointer second argumetn for nr*/ 

1 imi t = l; 

allocate are;_array_rsm; 

op="N"; 

if a_ptrs( 2)->p=nul 1 then do;/*Error handl i ng$$$ */ 

free ar <\_ar ray_dsm; 
call ns_error$p(U,op,nul 1 ,nul 1 ); 
end; 
/♦Error here is failure to specify an r for the rsm name*/ 

cal lname=addrel (a_pt rs ( 2 )->p, a_pt rs ( 2 )->p- >oset )-> 
1 abel_pl ate; 

cal 1 hcs_Sf s_search_get_wdi r(addr (wdi r ) J wd i r ) ; 
cal 1 hcs_$make_seg(wdi r, re1_name, rel_name, access_c 
ode / arg_array_rsm. return_arg( limit ) / err_code ); 

if err_code>0 then do;/*Error handl i ng$$$*/ 
free arg_ar ray_rsm; 

cal 1 GS_error$c(5,op, rel_name / nul 1 ); 
end; 
/*Error here is failure in make segment procedure*/ 

go to set up 7; 



i r : i ni t i ate_rel at ion : entry returns( poi nter ) ; 

cal 1 cu_$ar-_ptr(l / gen_purpose_ptr / 1 entty,er r_code 

); 

if err_code>0 then call GS_error$p( 6, "Z",nul 1 ,nul 1 

); 

/*Error here is null relation name*/ 
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1 imi t-1, 

allocate arg_array_rsm; 
op="Z"; 

cal 1 hcs_$f s_search__get_wdi r (addr (wdi r ) , 1 wdl r ) ; 
call hcs_$ i n i t i ate (wdi r, rel_name, rel_name, 0, 0, arg_ 
array_rsm. r l_pt r (1 i mi t ) , err_code ) ; 

if err_code>0 & er r_code~'=er ror_tabl e_$segknown th 
en do;/*Error handl i ng$$$ */ 

free arg_array_rsm; 

call GS_er ror$c( 1 , op, rel_name / nu1 1 ) ; 
end; 
/*Error here is failure to initiate relation specified in ir 
operat ion*/ 

cal 1 name=addrel (arg_ar ray_rsm. rl_ptr ( limit) , arg_ar 
ray_rsm. rl_ptr(limit)->r>set)->1abel_plate; 
go to setup7; 



sa : squash_array : entry returns (poi nter ) ; 

cal 1 cu_$arg_l i st_ptr (param_ptr ) ; 
if di spl ay_ ! f_8=8 then doset=arg_no+ 1; 
else doset=arg_no; 

if a_ptrs(l+doset )->dt_code" , = 29 then call GS_error 
$p(8,"A",nul l,nul 1 ); 

/*Error here is non array of pointers for first argument*/ 
1 imi t = 1 ; 

allocate arg_array_rsm; 
1 imi t=a_ptrs( 1+doset )->top_bound; 
if a_ptrs ( 1+doset )->low_bound~'=l then do; 
free arg_array_rsm; 

cal 1 GS_error$p(9, "A",a_ptrs ( l)->p,nul 1 ); 
/*Error here is non one lowver bound*/ 
end; 

al loc_length=0; 

al loc_order=a_ptrs (l)->p->order; 
do kk=l to limit; 

al loc_length=al loc_length + a_pt.'s (l)->indexor(k 
k)->qlength; 

do j j = 1 to alloc_order while (kk>l); 

if a_ptrs( l)->indexor (kk)->cent (j j )~'=a_ptr 
s(l)->p->cent ( j j ) then do;/*Error handl i ng$$$ */ 

free ar^_array_rsm; 

call GS_error$p(10 / " ", a_ptrs ( 1 )->p, a_ 
ptrs(l)->indexor(kk)); 

end; 
/♦Error here is inconsistant cent entries*/ 
end; 
end; 

allocate quart set (gen_purpose_ot r ) ; 
kik = l; 

arg_a,-ray_rsm.ql_ptr (ki k )=gen_purpose_ptr ; 
squash_sw=lb; 
new_pl ace=0; 
do kk=l to limit; 
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ero: procedure returns (po i nter ) ; 
% include mgr_decl are; 

eq:expand_quart : entry returns (pointer); 

cal 1 cu_$arg_l I st_ptr (param_ptr ); 
if d i spl ay_i f_8=8 then doset=arg_no+l; 
else doset=arg_no; 

if a_ptrs(l+doset )->dt_code"'=13 then call 0S_error 
Spdl," ", null, null ); 

/♦Error here is non pointer argument*/ 
1 imi t=a_ptrs(l)->p->qlength; 
allocate return_structure; 
al loc_order=a_ptrs( l)->p->order; 
al loc_length=l; 
do kk=l to limit; 

allocate quart set ( return_st ructure ( kk ) ) ; 
do jj=l to alloc_order; 

return_structure(kk )->cent(jj )=a_ptrs ( l)-> 
p->cent ( j j ) ; 

return_s t ructure (kk)->pent(jj )=a_ptrs ( l)-> 
p->pent ( j j ) ; 

return_st ructure (kk)-> tent (l,jj )=a_ptrs ( 1) 
->p->tent(kk / jj ); 

end; 
end; 

free a_ptrs( 1 )->p->auart : 
a_P t r s ( a r ^_n o ) - > p =• r e t u r n a H 1 r__p t r ; 

•?nd; 
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Mido: procedure returnst pointer); 
?; include :ngr_decl are; 

gr : ge t_ref no : entry returns( pointer); 

op = ,, R"; 

go to setuplO; 
sd : successor_data : entry returns ( pointer); 

op="S"; 

.^o to setuplO; 
gd : ge t_da ta : entry re turns ( po i nter ) ; 

op="D"; 

go to setuplO; 



/*Here check the general structure of arguments*/ 
setuplO: call cu_$arg_l i s t_pt r ( param_pt r ) ; 

if d i spl ay_i f_8=8 then doset = arg__no + 1; 

else dose t =a rg_no ; 

if ar";_no''2 then go to err_38; 

if a_ptrs ( 1+doset )->dt_code=13 then limit = l; 

else if a_ptrs ( 1+doset )->dt_code=29 then do; 
1 imi t=a_pt rs (1+doset )- > top_bound ; 
if a_ptrs ( 1+doset )- > 1 ow_bound"=l then call GS_ 
error$p(37,op,nul 1 , nul 1 ); 

/*Error here is non zero lower bound on input array*/ 
end; 

else err_38: call GS_er rorS p( 38, op, nu 1 1 , nu 1 1 ) ; 
/♦Error here is non pointer first argument*/ 

if arg_no>6 then call GS_er ror$ p ( 39,op, a_pt r s ( 1 ) - > 
p , n u 1 1 ) ; 
/♦Error here is illegal number of arguments*/ 



/*Here do the interpretation of the arguments*/ 
if op="R" then do; 

if a_ptrs (2+doset )->dt_code=13 then ptr_sw=lb; 

if arg_no<*4 then go to no_f ur ther_check; 
if a_ptrs( 3+doset ) - >d t__code = 13 then do; 
if limit=l then ski p_3_sw=lb ; 
else call GS_er ror $p ( U0,op, a__pt rs ( 1 ) ->p, a_ 
o t r s ( 3 ) - > p ) ; 

/♦Error here is inconsistent upper bounds on optional R argu 
ment */ 

end ; 
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else if a_ptrs(3+doset)->dt_code=29 then do; 

if 1 imi t=a_ptrs(3+doset)->top_bound then s 

ki p 3_sw=lb; 

~ else call GS_er ror$pUO,op,a_ptrs ( l)->p,a_ 

ptrs(3)->p); . 

/•Error here is inconsistant upper bounds on optional K argu 

(iient*/ 

end; 
no_f urther_check : if ~"ptr_sw then do; 

cal 1 cu_$arg_ptr(2,gen_purpose_ptr,as_Jen, 

err_code ) ; 

if err_code>0 then call GS_er ror$p( i4l,op, a 

_ptrs(l)->P/nul 1 ); 

/•Error here is incorrect format for MAM field*/ 

if as_len' , =U then call GS_error$c ( 42, op, ba 

sed_arg, a_ptrs( l)->p); 

nam=based_arg; 

nam_sw=lb; 

end; 

end; 

else do; 

cal 1 cu_$arg_ptr(2,gen_purpose_ptr,as_len,err_ 

code ) ; 

if err_code=error_table_$noarg then go to no_n 

ore : 

else if err_code>0 then call GS_error$pU3,op, 

a_ptrs (l)->p / nul 1 ); 

/•Error here is format error in argument 2*1 
if as_len=4 then do; 
nam_sw=lb; 
nam=based_arg; 
end; 

else go to read_arg; 
end; 



ii i=3; 
next_one: if skip_3_sw then if i i i =3 then iii=4; 

cal 1 cu_$arg_ptr( i i i , gen_purpose_ptr, as_l en,err_co 



de); 



if err_code=error_tabl e_$noarg then go to no_more; 



else if err_code>0 then call GS_error$p( k?> t ov, a_pt 

rs(l)->P,null ); 

/•Error here is format error in argument i i i •/ 
read_arg: if as_len<!» then do; 
opl ength=as_len; 

opt i on_sw=lb; 

opt ions=based_arg; 

end; 

else if as_len<33 then do; 

ent_sw=lb; 

ent=based_arg; 

end ; 

else call GS_er ror$c (M^op, based_arg,a_ptrs ( 1 )->p) 
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/*Error here is argument of string size greater than 32*/ 
if i i i =5 then go to no_more; 
else iii=iii+l; 
f,o to next_one; 

/*Here allocate the proper size argument array*/ 
no_more: if option_sw !k ( i ndex (opt i ons, "E" )~" = I i nrlex Copt i on 
s,"e")" , = 0) then do; 

squash_sw=lb; 

if 1 imi t> 1 then call GS_error$p( ll,op, a_ptrs ( 1 
)->p,nul 1 ) ; 

/♦Error here is feeding array to conceptual expand_quart ope 
rat ion*/ 

el se 1 imi t=a_ptrs (l)->p->qlength; 
allocate arg_array_dsm; 
1 imi t = l; 
end; 
else allocate arg_array_dsm; 



/*Here set opcode and options slots*/ 
arg_array_dsm.opcode=op; 
/* Here scan the options*/ 
if option_sw then do; 

arg_array_dsm. d_or_i_opt ion = " "; 

if (index(options / "D")" , =0| i ndex ( opt ions, "d")^ = 



0) then 



arg_array_dsm.d_or_?_opt ion="D"; 
if op = "R" ft ( indexations, "l H )-»0| index(optio 
ns / "i")^=0) then 

ari T ,_array_dsm. d_or_i_opt ion=" I "; 
if squash_sw then ar^_ar ray_dsm. e_opt i on="E"; 
else ar; T ,_ar ray_dsm. e_opt i on=" "; 
do kik=l to 3; 

mm=index("12 3U5 6 78 9" / suhstr(options / kil</l) 



); 



stop_co1 



ption=" "; 



if mm~' = then do; 

col umn_index=mm; 
go to stop_col ; 
end; 
end ; 

end; 

el se arg_array_dsm.d_or_i_opt ion, arg_arr ay_dsm.e_o 



/*Here set the return arg slot with given pointers 

, if needed*/ 

do kk=l to limit; 

if skip_3_sw then arg_array_dsm. return_arg (kk ) 
=a_pt rs (3)->indexor(kk); 



-168- 
el se arg_ar ray_dsm. return_ar^( kk )=nul 1 ; 
end; 

/*\iere do consistancy checking on the pents or cen 



ts*/ 



if ~'nam_sv/ & ~'ptr_sw then do; 
IF 1=0; 
do kk=l to limit; 

if a_ptrs (l)-> i ndexor (kk)->quart. pent (col u 
mn_index)""=nul 1 then do; 

if i I I =0 then i i i=kk; 

else if a_ptrs(l)->indexor (kk)->quart . 
pent (col umn_.index )"" = 

a_ptrs( l)->indexor(i i i )->quart. pen 
t (col umn_i ndex ) then do; 

free arg_array_dsm; 
cal 1 GS_error$p(^5,op,a_ptrs ( l)->i 
ndexor (kk),a_ptrs ( 1 )-> i ndexor ( i i i ) ) ; 

/♦Error here is inconsistant data type by non null pents*/ 

end; 
end; 

i f substr (a_ptrs( l)-> i ndexor (kk)->cen t (col 
umn_ index), 1 / U)"' = 

subs tr (a_ptrs(l)->p->cent (col umn_i ndex 
),1,U) then do; 

free ars_array_dsm; 

cal 1 G S_e r ro r $ccO* 6, op, a_ptrs ( l)->p->c 
en t (col umn_index) / a_ptrs( 1 )-> i ndexor (kk )-> 

cent (col umn_ index) ) ; 
end; 
/*Error here is inconsistant data types by cent name*/ 
end; 
end; 



r(kk); 



/*Here fill in first arguments*/ 
do kk=l to limit; 

arg_array_dsm.d_or_q_ptr (kk )=a_ptrs ( l)-> i ndexo 

end; 



/•Here construct the ddptr*/ 
if ptr_sw then do; 

arg_array_dsm.data_data_ptr=a_ptrs (2)->p; 
end ; 
else if " , nam_sw then do; 

if i i i =0 then do; 

i i i =1; 

call hcs_$f s_search_get v/d i r (addr (wdi r ), Iw 
d i r ) ; 

cal 1 hcs_$ initiate(wdir / substr (a_ptrs (l)-> 
p->quart. cent (col umn in flex), l.k) . 
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substr (a_ptrs( l)->p->quart. cent (col umn_i 
ndex),l,iO,0,0, a_ptrs (l)->p->quart. pent (col umn_ index ), 

er r_code ) ; 
if err_code=error_tab>1 e_$segknown then do; 
end; 

else If err_code>0 then do;/*Error hand! in 
S$$$*/ 

free arg_array_dsm; 

call GS_error$c C*7,op,a_ptrs ( l)->p->ce 
nt (col umn_index) / a_ptrs( l)->p); 

end; 
/*Error here is failure in get seg ptr or initiate procedure 

*/ 

end; 

arg_array_dsm. data_data_pt r = a_pt rs ( 1 )-> i ndexor 
(ii i )->quart.pent(col umn_ index ); 
end; 
else do; 

call hcs_$f s_search_get_wdi r (addr (wdi r ), Iwdi r ) 



(nam, 1, k ) , 



*/ 



call hcs_$ initiate(wdir,substr(nam,l,'0,substr 

0, O,ar^_array_dsm.data_data_ptr / err_code) ; 

if er r_code=error__tabl e_$segknown then do; end 

else if err_code>0 then do;/*Error handling$$$ 



free arg_array_dsm; 

cal 1 GS_error$c(U8,op,nam, a_ptrs (l)->p); 
end; 
/*Error here is failure in get seg ptr or intitiate procedur 
e*/ 

end, 



/*Here set callname and issue call to dsm*/ 

cal lname=addrel (data_data_ptr,data_data_ptr->oset ) 
->label_pl ate; 

cal 1 hcs_$make_ptr ( M ",cal 1 name, cal lname, xfer,er r_c 
ode ); 

if err_code>0 then do; 
free arg_array_dsin; 
cal 1 GS_error$c('t9 / op / cal lname / nul 1 ); 

end; 

cal 1 cu_$ptr_cal 1 (xf er, arg_ptr ) ; 



/*Here do post call processing like filling in ret 
urn args and ent*/ 

do kk = l to 1 imi t; 

if (op = l, S ,l !op="R") & ent_sw then do; 

arg_array_dsm. return_arg( kk )->quart . cent (c 
ol umn_i ndex)=ent; 
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odo : procedure returns (pointer); 
^include mgr_declare; 

nd :new_data_type : entry returns (poi nter ) ; 

cal 1 cu_$arg_l 1 st_ptr (param_ptr ); 

if di spl ay_if_8=8 then doset=arg_no+l; 

else doset=arg_no; 

cal 1 cu_$arg_ptr(2,gen_purpose_ptr, 1 entty, err_code 

); 

if err_code>0 then call GS_error$p(28, "N ,, / nul 1 ,nul 

1); 

else cal 1 name=rel_name; 

/*Error here is non label second arg*/ 
1 i m i t = 1 ; 

allocate arg_ar ray_dsm; 
do; 

cal 1 cu_$arg_ptr ( l / gen_purpose_ptr / dl en,err_co 
de); 

if err_code>0 then do;/*Error handl i ng$$$*/ 

free arg_array_dsm; 
cal 1 GS_error$p(29 / ll M" / null / null ); 
end; 
/*Error here is incorrect first argument*/ 

if dlen"'=U then do;/*Error handl i ng$$$*/ 
free arg_array_dsm; 

cal 1 GS_error$c(30, u N",based_nam,nul 1 ); 
end; 
/♦Error here is incorrect length for data type name*/ 

cal 1 hcs_$fs_search_get_wdi r (addr (wdi r ), lwdi r ) 

call hcs_$make_seg (wdi r, based_nam / based_nam / ac 
ce ss_code 7 a rg_a rray_dsm.dat a_data_ptr, err_code); 

if err_code>0 then do;/*Error handl i ng$$$ */ 
free arg_array_1sm; 

cal 1 GS_error$c(31, "N", based_nam, nul 1 ); 
end; 
/♦Error here is failure in make seg procedure*/ 

arg array dsm.opcode="N"; . . . , 

arg_array_dsm. h i gh_bound=l imi t ; * ^ * ' 
cal 1 hcs_$make_ptr ( Im ,cal 1 name, cal lname / xf er,err_c 
ode ); 

if err_code>0 then do; 

free arg_array_dsm; 

call GS error$c(49,arg_array_dsm.opcode / cal lna 
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me, nul 1 ) ; 

/♦Error here is Illegal callname*/ 

end; 

cal 1 cu_$ptr__cal 1 (xf er, arg_ptr ); 

a_otr-( ir";_no) ->p = dri ta_Ha ta_pt r ; 
re tu rn ; 

kd :ki 1 l_data_type: entry returns (poi nter ) ; 

1 i m i t = 1 ; 

cal 1 cu_$arg_l i st_ptr (param_ptr ) ; 

if di splay_if_8=8 then doset=arg_no+ 1; 

else doset=arg_no; 

if a_ptrs(l+doset)->dt_code=520|a_ptrs( 1+doset )->d 
t_code=522 then do; 

cal 1 cu_$arg_ptr(l,gen_purpose_ptr, lentty,err_ 

code ); 

if err_code=error_table_$noarg then call GS_er 

ror$p(32 / "K" / nul l,nu! 1 ); 

else if err_code=0 then do; 

if lentty^U then call GS_er ror$c ( 33, "K", r 

el__name, nul 1 ) ; 

cal 1 hcs_$f s_search_get_wdi r (addr (v/d i r ) , 1 w 

dir); 

cal 1 hcs_$delentry_f i le(wdi r, based_nam, er r 
_code ) ; 

if err_code>0 then call GS_er ror$c ( Ik, "K", 

based_nam / nul 1 ) ; 

/♦Error here is failure in initiate or in mget seg ptr*/ 
end; 
end; 
else if a_ptrs ( 1+doset )->dt_code=13 then do; 

if a_ptrs( l)->p->quart. pent ( 1 imi t )=nul 1 then d 

o; 

cal 1 hcs_$f s_search_get_wd i r (addr (wd i r ) , 1 w 

dir); 

cal 1 hcs_$ini ti ate(wdi r , subst r (a_pt rs ( l)-> 
p->quart.cent(l imi t ), 1, U ), 

substr (a_ptrs(l)->p->quart.cent(l imi t ) 
, l,h), 0, O,gen_purpose_ptr,err_code); 

if err_code=error_table_$segknown then do; 

end; 

else if err_code>0 then call HS_er ror$c ( 35 
/ "K" / a_ptrs(l)->p->cent(l imi t ), a_ptrs ( l)->p ); 
/•Error here is failure in initiate or in get seg ptr*/ 
end; 
else gen_purpose_ptr=a_ptrs (l)->p->quart. pent ( 

limit); 

cal 1 hcs_$delentry_seg(gen_purpose_ptr / err_cod 

e ); 

if err_code>0 then call GS_er ror$p( 36, "K", gen_ 
purpose_ptr, nul 1 ); 

/♦Error here is failure in delete seg procedure*/ 
end; 



Wed 
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<'s>GS_error . pi 1 



05/20/70 1059. U edt 



GS_error: procedure; 

dec 
r, poi nter ) ; 

dec 
), pointer ) ; 

dec 
(*),char(*)); 

dec 

dec 

dec 

dec 

dec 

dec 

dec 

dec 

dec 

dec 

dec 

dec 



are (p,pr) entry (fixed b i n ( 17 ) , char ( 1 ) , po i nte 
are (c,cr) entry (fixed bi n ( 17 ) / char ( 1 ) ,char (* 
are (cc / ccr) entry (fixed hi n ( 17 ),char (1 ) ,char 



are code fixed bin(17); 
are op chard); 
are (pl,p2) pointer; 
are (cl,c2 ) char (*); 
are err_code fixed bin(17); 
are puse pointer; 
are pi_label label static; 
are GS_er ror$pi entry external; 
are buffer char(120) initiaK" "); 
are num_i tems fixed bin(35) i n i t i al ( 120 ) ; 
are ascode char(12); 

are (cond_f 1 ag, P_sw, r_sw, c_sw, cc_sw) fixed bin 
(1) initial(Ob); 

declare 1 quart based (quart_ptr), 
2 ID fixed bin(35), 
2 qlength fixed bin(35), 
2 order fixed bin(35) / 
2 centd refer (order)) char(32) / 
2 pent(l refer (order)) pointer, 
2 tentd refer (qlength),l refer (order)) fixe 
d bin (35); 
pr: entry (code,op, pi, p2 ) ; 

r_sw=lb; 
p: entry (code, op, pi, p2 ) ; 
p_sw=lb; 
go to message; 
cr: entry (code, op, cl, pi ) ; 

r_sw=lb; 
c: entry (code, op, cl, pi ); 
c_sw=lb; 
.^o to message; 
ccr: entry (code, op, cl, c2 ) ; 

r_sw=lb; 
cc: entry (code, op, cl,c2 ); 

cc_sw=lb; 
message: call ioa_("GS: Error ""5d Internal opcode ""a'^code, 
op); 

if cc_sw then call ioa_(" Name 1: "'a Name 2: "" 
a M ,cl,c2); 

else if c_sw then do; 

call ioa_$nnl(" Name 1: "'a ",cl); 

if pl"=null then call ioa_( M Pointer 1: "p",pl 



)', 



"p ",p1>; 



"P ",p2>; 
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else call ioa_(" "); 

end; 

i f P_sw then do; 

if pl~ , =nu11 then call ioa_$nnl(" Pointer 1: 

if p2^=null then call ioa_$nnl(" Pointer 2: 

if pl^=nul 1 |p2*"=nul 1 then call ioa_(" "); 

end ; 

call cv_bin_(code,ascode, 10); 

call ioa_$nnl(" "); 

cal 1 pr int ("0S_err_mes sages", ascode / ascode ) ; 
new_try: if r_sw then call ioa_$nnl(" Type procedure na 
me, return, or quit..."); 

else call ioa_Snnl(" Type procedure name, or qu 
it..."); 

cal 1 ios_$read_ptr (add r (buffer ),num_i terns, kk ); 

if r_sw & substr (buffer, 1, kk-1 )= n return" then retu 
rn; 

if substr (buffer, 1, kk-1 J^'qui t" then call signal_( 
"G0LD_STAR"); 

cal 1 hcs_$make_ptr( l,n , substr (buffer, 1, kk-1), substr 
(buffer, 1, kk-l),puse,err_code) ; 

if err_code>0 then call ioa_(" Mo such procedur 
e can be found!"); 

else call cu_$ptr_cal 1 (puse) ; 

go to new_try; 

end; 



2 



Wed 
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<s>GS„err_messages 05/20/70 1128. h edt 



I Argument for nr operation not found, 
nr operation does not have two arguments plus return argumen 
t (non_f unct i onal invocation is illegal). 

3 Second argument of nr operation is not a pointer. 

4 Second argument of nr operation is a null pointer. 

5 Make segment procedure in nr operation failed - name provide 
d is attempted relation name. 

6 Argument not found for ir operation. 

7 Initiate procedure failed for ir operation - name provided i 
s attempted name. 

8 Argument for sa operation is not an array of pointers. 

9 Low bound of argument ( poi nter 1) is not one. 

10 CENT i nconsi stancy found between elements of array of pointe 
rs in sa operat Jon(poi nter 1 and 2). 

II Argument in eq operation must be pointer. 

12 Too few arguments-must be at least one plus return for funct 
ional invocation. 

13 First argument must be pointer or array of pointers. 

14 Low bound of first argumen t ( po i nter 1) must be one. 

15 Too many arguments ( po i nter 1 is first one). 

16 All arguments must be pointers if first one is(pointer 1). 

17 All arguments must be arrays of pointers if first one i s ( po i 
nter 1 ) . 

18 Upper bound of input argument ar rays ( poi nters 1 and 2) are n 
ot the same. 

19 Operation cannot have more than one argument (po i nter 1). 

20 Operation must have more than one argument ( po i nter 1). 

21 Successor cannot have relation as second argument(arg l=poin 
ter 1, arg 2=pointer 2). 

22 First operand cannot be null. 

23 First argument is array of relation pointers calling for i nc 
onsistant RSM( po i nters 1 and 2). 

24 Second argument is an illegal array of quart and relation po 
in ters (poi nters 1 and 2). 

25 Second argument is array of relation pointers calling for in 
consistant RSM(pointers 1 and 2). 

26 Make segment procedure failed - arguments one and two are po 

inters 1 and 2 . 

27 Change name procedure has failed on segment of pointer 1. 

28 Illegal second argument for nd operation. 

29 Illegal first argument for nd operation. 

30 Data type name (Name 1) in nd operation is not four characte 
rs . 

31 Make segment procedure has failed during nd operat ion (name a 
t temp ted was Name 1). 

32 Mo argument given for kd operation. 

33 Type(Name 1) indicated in kd operation not four characters. 

34 Delete segment procedure failed during kd operat ion (name att 
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78 
79 

SO 
3 1 
S2 
8 3 
Sk 
8 5 
86 



89 
90 
91 
92 
93 
9 k 
95 
96 
97 
9 3 
9 9 

lOOOve 
tu r 

1 10 r d 
i Id 

10 29 EM 
Ids 

1 31 ! i d 
r o 
101+ 
105 



Mapping CE'JT in cp operation between Pointer 1 and 2. Re 

n ye i Ids null pointer. 

ers of quarts (r>ointers 1 and 2) are not equal. Return ye 

s null result. 

T of quarts (pointers 1 and 2) do not overlap. Return ye i 

null result, 
th of equivalence vec to r ( Po i n ter 2) must be equal to orde 
f qua r t ( Ro inter 1 ) . 



Wed 



-179- 
<s>gsdb.p1 1 



05/20/70 1053.3 edt 



:sdb 



bin(35); 



35)); 



procedure; 

declare 1 dsm based (inptr), 
2 dtop fixed bind?), 
2 cindex fixed bin(17), 
2 dop chard), 
2 di chard), 
2 eopt chard), 
2 ddptr pointer, 

2 dqptr (1 refer (dtop)) pointer, 
2 dretptr d refer (dtop)) pointer; 
declare 1 rsm based (inptr), 
2 rtop fixed bin(35), 
rop chard), 
ql d refer (rtop)) 
(rtop)) 
(rtop)) 
(rtop)) 
(rtop)) 



rl 
q2 
r2 
ep 



(1 
(1 
(1 
(1 



refer 
refer 
refer 
refer 



2 
2 
2 
2 
2 
2 

2 rretptr (1 refer (rtop)) 
declare 1 quart based (inptr), 
2 ID fixed b?n(35), 
2 qlen f i xed bin (35 ), 
2 qorder fixed bin(35), 
2 cent (1 refer (qorder)) 
2 pent (1 refer (qorder)) 
2 tent (1 refer (qlen),l 



poi nter, 
poi nter, 
poi nter, 
po i n t e r , 
pointer, 

pointer; 



char(32), 
po i n t e r , 
refer (qorder) 



f i xed 



declare 1 entvector based (inptr), 
2 width fixed bin(35), 
2 ents (1 refer (width)) char(32); 

declare ssdb$p! entry external; 

declare (d,r,q,e) entry (poiater) external; 

declare call_sw fixed bind) initial(Ob); 

declare pi_label label static; 

declare op charU) initiaH" "); 

declare buffer char(132); 

declare (baseptr, addrel ,min, substr, i ndex ) builtin; 

declare cv_oct_ entry external returns (fixed bin( 

declare woffset fixed bin(35) initial (0); 

declare wptr pointer initial (null); 

declare (inptr, aptr) pointer; 

declare (nun, kk, i i ,orpl ace, endpl ace ) fixed bin(17); 



call ioa_( M ASK! M ); 
cal l_sw=lb; 
pi_l abel =read; 



read 



-180- 
cal 1 i os_$read_ptr(addr (buffer ), 132, kk); 
op=substr (buffer, 1,1); 
if op="." then return; 
if op" , = ,, d" h op"="r" h op- = "q" h op-="e" then do; 

call ioa_("?"); 

go to read; 
end; 
do mm=2 to kk-1; 

if substr(buffer,nm,l)" , =" " then go to start_n 



o; 



end; 

go to no_offset; 
start_no: orpl ace* I ndex (buffer, " | "); 
if orplace=0 then do; 

orpl ace^mm-l; 

go to offset_only; 
end; 
wptr=baseptr (cv_oct_( subs tr (buffer, mm, orpl ace -mm) ) 

); 

offset_only: do ii=orplace+l to kk-1; 

if substr(buffer,i i,l)»" " then do; 
endplace = i i ; 
go to end_found; 
end; 
end; 

endpl ace^kk-l; 
end_found: mm=endplace+l-orpl ace; 

if mm=0 then go to no_offset; 

wof f set=cv_oct_( substr( buffer, orpl ace+1, mm)); 
no_offset: inptr=addrel (wptr,wof f set ); 
go to output; 



d: 



r : 



e : 

labset : 
output : 



entry (apt r ); 

op="d"; 

go to labset; 

entry(aptr ); 

op="r"; 

go to labset; 

entry(aptr ); 

op="q"; 

go to labset; 

entry(aptr ); 

op="e"; 

pi_l abel =back; 

inptr=aptr; 

if inptr=null then do; 

call ioa.C'NULL!"); 

go to done; 



end 
cal 
cal 
if op="q" then do; 



1 condi tion_( M program_interrupt",gsdb$pi ); 
1 ioa_("AT ^p",inptr); 
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do i I =1 to qorder; 

call ioa_("-16a -p",cent ( i i ),pent ( ii ) ) ; 
end ; 
do ? i =1 to qlen; 

do mm=l to qorder; 

call ioa_$nn1 ("-8d ", tent ( i i ,mm) ) ; 

end; 

call ioa_(" "); 
end; 
end; 
else if op»"r" then do; 

call ioa_("Sound -3d Op -la", rtop, rop) ; 
call ioa_("Ql Rl Q2 R2 
EP RET"); 

do I i =1 to rtop; 

call ioa_("-p -p -p "P "P V,qK H ), rl( i i 
) / q2(i i ),r2U I ),ep(i ! ),rretptr(i I )); 
end; 
end; 
else if op»"d" then do; 

call Ioa_("Bound ^3d Op -la Dl option -la 
E option -la C option -Id DDptr -p", 

dtop / dop / di / eopt / cindex / ddptr); 

call ioa_( M D or Q RETURN"); 
do i i =1 to dtop; 

call ioa_("-p -p",dqptr ( i I ),dretptr ( i i ) ); 
end; 
end; 
else do i i =1 to width; 

call ioa_("-16a ,, ,ents(i i )); 
end; 
done: if call_sw then go to read; 

el se 
back: return; 



pi : entry; 

go to p t 1 abel ; 

end; 
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d*m astrin^.oll 



'Ion 



OG/01/70 2ior. r - -^t 



dsm_as tr i n^: procedure (rJsn_nr r s_otr); 

del datn_scf; area (arco_sizr) based (sn^_ptr); 

del 1 quart baser! (quart_ptr), 
2 id fixed binary (35), 
length fixed bin (35), 
order fixed bin (35), 
cent char (32), 
pent Ptr, 
tent fixed bin (35); 



del 1 quar t__proper based (uart_ptr),, 

qid fixed hin (35), 

qtenrth fixed bin (35), 

qorder fixed bin (35), 

qcent (qorder' c^ar (32), 

qpc-nt (qorder) ptr, 

qtent ( ql en^t^, norde r) fixed Sin (35); 
del 1 tnt_quart static, 

2 mtid fixed Hin (35) initial (0), 
2 mtlenpth fixed bin (35) initial (0), 
2 mtorder fixed Sin (35) initial (1), 
2 mtcent char (32), 
2 ntpent ptr; 



2 

1 

c 

O 

L. 

2 
2 

9 



del 1 



del 1 



ds 

2 

2 

2 

2 

9 



;rn_arn;s based ( ds r n_ar n :s_pt r) , 
upper_bound fixed binary (17), 
ci f i xed bin (17), 
op char (1), 



op char (1), 
di char (1), 
e char (1), 



2 dd ptr ptr, 



d_ 



u_or_q_r>tr (unper_bound) ptr, 
return_ptr (upper_bound) ptr; 



type based (type_ptr), 

2 dsm_nane char (1G), 

2 data_type char ( 32), 

num_f ree_cel 1 s fixe'' Sin (35), 
nun_entries fixed bin (35), 
max_l ensth fixed Sin (35), 
first_entry offset (da ta_se»r) , 
successor_chai n_head offset (data_sep;); 



del 1 item based (iptr), ' 183 " 
2 lpt.r offset ( da ta_ser) , 
2 rptr offset (data_se- T ) , 
2 succ offset (data_se^), 
2 flap: fixed binary (35), 
2 refno fixed bin (35), 
2 s tr i nr_s trurtu re, 

3 strinr_ length fixe-! Winery (35), 

3 strinr character (^ax_l en^t'O ; 

del 1 area_scg bas^d (se°;_ptr), 

2 first_nff offset ( da ta_se";) , 
2 curr_len offset (data_se< T ), 
2 next_off offset (data_ser) ; 

del 1 pseudo_s tr inr_array based (str_ptr), 
2 pseudo_l en,~th fixe'! Si nary (35), 
2 i nput_or_return_s tr i nr. cKtt (mlen_int); 

del (ptr, new_ptr, succ_ptr, type_ptr, new_se^_ptr, 
quar t_ptr,sep;_ptr, i ptr, str_ptr) ptr static; 

del dsm_ar^s_ptr ptr; 

del (area_s ize, i,ii / fourd / pilen_int,diff,''!?ffer,turn,nres^P 
ted_l oop_ref no, sto red_l oop_ref no, 

i i i , i k, !-, <rrerh) fixed binary (35) static; 

del (nax_depth_of_trec initial (3'0,le^t initial (10), ri^^ 
t initial (20) fixed binary (35) static; 

del return_label la^H ( i nsor t_re tu rn, da tun_return, ref no_r 
eturn, suceessor_rn tur n, 

de 1 e te_by_ref no_rotu rn, del eto_by_d 
atuni_return, r_, d_, s_, i_/ rd, dd) ; 

del dbd_label (-1:1) label (beM n_ds^_as t r ! nr) static; 

del dbr_label (-1:1) label (beri n_ds r i_as t r I nO static; 

del succ_label (-1:1) label ( beri n_dsn__ast r i nO static; 

del insort_label (1:1) label (ber; i n_dsn_ast r i n";) static; 

del ins_comp_l abel (-1:0) label (beri n,dsm_as t r i n°;) static 



del enane char (32), dirnane c^vr (163) static; 

del (presen ted_l eop_s tr i nr, stored_l or»r,_s t r i n^) character ( 

1 6 S ) varying static; 

del (exp, dor i , opcode) char ( 1) varying static; 
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dcl treo_res tructurc entry ( po i nt^r, noi n tor, poi nto r ) , 

(ar^a_$ rodef ,area_) entry (fixe- 1 binary ( 7 7) , pol ntor) 



del (nu 1 1 , nu llo, subs t r, di v i Ho, a'!rlr<"> 1 , ni n, ad-! r) bui 1 tin; 

del (of f, cu rr, next, code) fixod binary C*>5) static; 

del (t1 !ch / las t_l ef t, 1 ast_r r -rh t ) offset (date_sc~) static; 



dc 1 ( di-.d_l ab_sw, db r_l ah_sw, I ns_l ah_sw, succ_l ab_sw) f ? x<H k 
in (35) static initial (0); 



.•c.r'\ n_dsn_as tr inn: 

c x p = d s m_a r t s . o ; 
co r i = dsn_or.TS . d i ; 
opcode =dsn_ar ^s . np; 
sciLPtr =dsm_ar <ts . ddptr ; 
type_pt r = f i rs t_of f ; 

if opcode="D" then /* input is refnos */ 
if dor?=" " then to to Tot_datun; 

else if dori="P" then eo to -*o 1 otr_by_ref no; 
else to to op_error; 



else if opcodo=" n " t h on 



/* data strings ^r^ input */ 



if dori=" " thon to to Tet_refno; 

else if dori ="n" t'^en po to dc 1 ^t^__by_da tun; 



else if dori 



_it I ii m 



t K en ro to insert; 



else ^o to on_error; 

else if oocodr="S" thon 

if dori ='■' " then to to successor; 
else to to op_error; 



else if opcodp = '""' then 

if (dori=" " " exp = " ") then ro to new_d.ata_.type; 
else go to op_error; 



else go to op_error; 



/************************************/ 
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new_da ta_type : 

do ii =1 to upn"r_ h o ; in'!; 

call area_( 1 H 2 's- , snr_ptr) ; 

co 1 1 hcs_$ f s_f;e t_pa t^na^r ( se^_pt r , Hi rn-nr, "r^c u 
, enane, code) ; 

allocate typo set (tynr_ptr) in (data_se«;); 

nuni_on tr i rs=0 ; 

nu^i_f rrn_cr>l 1 s =0 ; 

call ioa_("wHat is nnx lro^t^ for character stri 
nns for ~'a>~ , a ?" , /",su t istr(r , irnm^ / l^r^^'^^nme); 

call read_l i s t_( qr^cH) ; 

max_lon^tb=.^rnch; 

successor_cHai n_hcad=nu 1 1 o; 

da ta_typo=onaTic; 

dsn_namo = "dsn_as t r i n^," ; 

f i rs t_entry=nu1 1 o; 

end; 
return; 



/•A**********************************/ 



f-;rt_cla tun: 

do i i = 1 to ii i»prr_bound; 
rr tu rn_1 ah rl =da t'jn_r^ tu rn; 
GO to rcf no_pro! o<-ur ; 
da tum_rc tu rn : 
if found = 1 *■ ptr->flar = l then Ho; 
r e t u r n_ 1 a h e 1 = d_ ; 
qo to strin.ff_nllor; 
d_: 
pseuHo__l enrth =ptr->s t r i n~_l ^n~t 1 -; 
i npu t_or_retu rn_s trin" = s i jSstr(ptr->strin" ; l / ntr' 
>string_lenr:th) ; 
end; 
else d o ; 

dsm_arfrs. roturn_ptr( i i ) =adH r (mt_quar t) ; 
ntcont =da ta_type; 
mtpen t=ser;_Pt r; 



end; 



end; 
re tu rn ; 



/************************************/ 
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get_ref no: 

do i ! =1 to upppr_houn'l; 
re tu rr_1 n be 1 =ref no_ return; 
go to da tun_prologiK: ; 
ref no_rp turn: 
if found=l *j Dtr->f1n"- = l t u en do; 
return_l ahel =r_; 
go to quart_a11or; 

r__: 
tent=ptr->rofno; 
end; 
el so do; 

dsn_args . return_pt r ( i i ) =a^r(mt_quart ) ; 
ntcent=dotri_typo; 
n t pen t =s e r_P t r ; 
end; 
end; 
retu rn; 



/**************************•**********/ 



iucccs sor : 

if 5UCC_lob_sw = 3 then <-'<->; 

succ_Jab_s\7 = l ; 

succ_Jabol ( - 1) =sunc_I t_0 ; 

succ_label (0) =succ_eq_0; 

succ_label ( 1 ) =suce_gt_0 ; 

end; 
do ii = 1 to upprr_hound; 

retu r n_l abol =s_; 

go to quart_a!1^o; 
s_: 

succ_ptr =quar t_ptr ; 

returt_1ahel=5'Jcc^ssor_rrturn; 

go to r ef no_p rol o"ue ; 
succos5or_roturn: 

go to suec_l abe 1 ( fourH) ; 



surc_eq_0 : 
if tu rn = l ef t then A o; 

if l.Tst_ri"Ht=n'.il !o t^rn H o; 
ptr=succns'jn r_c l o i n_h e o '' ; 
if ptr->flag=1 t K nn do; 

succ_ptr-> ten t =ptr-> ref no; 
go to surcosL.or_end ; 
end; 
else go to succ__gt_0; 
end; 
else ptr = 1 ost_r i g!'t; 
end ; 
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b u CC_" i 
If )!r 



i^r. = rr.; 1 1 n 



r< t j r •"_": t r ( i i ; 
,-tcor, t = ■'.<-, tr. ty 



r (:i t_qur r t ) ; 



-i t. ;-.r r t =s ^ r_P t r ; 

pp ■_ p ■:, 'jccrh:, " i'_on-' ; 

r- r ' 

i • 1 \, i- \ r p t r - l ; ' s [ ! •" p ~ "> r 1 r. ^ = 1 t l ■ p p ' '■ ; 
.j ■ i ■". c r> t r - "■ t '"■ "t = nt".r-)s;i^r-> r r r ^ n ; 
~ p to jmccoss o r_o h ' J ; 

o 1 s o ■ I o ; 

~ l i c ' - : -it r - > b 1 1 c - ; 
P t r ~ r ' 1 i o u ; 



on '; 



b U CCPb bO r_o 
r ( ■ L J r p ; 



it********* * * 



******* 



* * * *■********/ 



ins lab b .-■ 



n s p r t 



* 1 - s 



1 ( - 1 ) = i -s_J t_" ; 



i r s o r t_ 1 a h p 1 ( 1 ) = i n s_"( 1 _j ; 
i n s e r t_ 1 n ^> p 1 ( 1 ) = i n b _p t_ b ; 
ins_conp_l pbrl ( - 7 ) =i nb_c.p 'p_l t_0 ; 
i nb_comp_1 pSp 1 ( ) = i ns_c^" ,, i_^'"_n ; 

j i i = 1 to u pprr_boii v' ; 
r r lur n_ 1; 'tI =irs°r t_ r ° t • i r p ; 

" O tO C a t 'J P_ P r o 1 n ~ i ; p ; 

nsrr t_r r t .; r r : 

rr tu r n_l p k p! ^ i_; 

"o t o p L'P r t_< 1 ]->■"; 

p o to ir'brrt_] l s. ; ( f n ■ j n ! ) ; 



i nb_l t_D : i r i_pp_: : 
ul locate It p.--- :, ° t. ( i ^ t f ) in ( (in t r__s rwT ) ; 
■ f i n t r =nu 11 t h pp 'In ; 



pall p r ! 



b r o o r ■■ 



( '.i n 5 ' ) ■" p ( s u s s t r ( b i t ( u p s "3 p c ( n e x t __o ^ r ) 



,!?■), 1, IS) >+102~, spp_otr) ; 
30 to i r b_i t_3 • 
end ; 



-188- 

1 ptr =nu 11 o; 

rptr =nu 1 1 o; 
flac=l; 

s tr i np;_l encth=pseudo_l nr.rt h ; 

str i nr=suhs tr ( 1 npu t_or_rotu rn_s t r i n T , 1 , ^1 n (max_l rr^t K , 
pseudo_l onrth) ) ; 

ZO to i n G_comp_l aSo 1 (found); 

• ns_comp_l t_0 : 
succ=nul 1 o ; 
rrfno = 1717nSGD18fi; 
tont=171798691CU; 
f i rst_entry=i ptr; 
succosso r_c H a i n_h r> a '! = ! n t r ; 
^o to ins_incr; 

i ns_comp_eq_0 : 

d i f f =Tiax_depth_of_t ree-i ! i ; 
differ=l; 
do lk=l to diff; 
di ffrr=2*diffrr; 



end; 



do; 



i f tu rn = r i ^h t then 

ptr->rptr=iptr; 

iptr->succ=ptr->succ; 

ptr->succ = i ptr ; 

iptr->refno=ptr->ro^no+differ; 

tent'=iptr->rf > fno; 

30 to ins_lncr; 

end; 
else do; 

i ptr->succ=ptr ; 

ptr-> 1 ptr=iptr ; 

iptr->rofno=ptr->rcfno--nffer; 

tent=?ntr->refno; 

if las t_r I ?;b t=nu 1 1 o f-rn s!j<:cossr>r_r , ->a i n_head=i nt r ; 

else 1 as t_r i *ht->succ=i nt r; 

r;o to ins_incr; 

end; 



i ns_ r ;t_0 : 
trnt=ptr- N rofno; 
if ptr->flar;=0 t h en Ho; 

P t r - > f 1 a r. = I ; 

num_f rce_ce 1 1 s=nun_f ree_ce 1 1 s-1 ; 

end; 

else £0 to insorl_end; 
ins_incr : 
nun_entr i rs=niri_en t r i es + 1; 



i n s e r L_e n ri : 
return; 



arid ; 
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•a*********************************/ 



d o 1 e t r_b y_ r o f no : 

if dbr_jc-:b_s\v = then do; 
dbr_lahol (-l)=dbr_l t_0 ; 
cbr_lobel (0) =dbr_eq_0; 
dbr_lobel ( 1) =dhr_?t_0 ; 
db r_l ab_sw = l; 
end ; 
do ii = 1 to i.jppor_bour, r\y 

return_ label = do 1 ote_by_r^ fnn_re turn ; 
zo to rofno_p ro Iotu^; 
del etr_by_rr>f no_rr> t'l rn : 
r,o to f!br__lnbpl (found); 

dbr_lt_0: <-!<-, r _on_0 : 
dsn_a r r,s . r e turn_p t r ( i i ) =0'! r'r (rnt_.nt.jrr t ) ; 
ntcent=da to_tyoe; 
ti t pe n t = s e h_p t r ; 
^o to del ote_by_ref e^en^; 



^ n r; t h ) ; 



dbr_^t_0 : 

if ptr-> f 1 ns=Q then r;o to dbr_er\_0; 

else; 

ptr->f lae=0; 

num_entr i rs=ni.n_cntr i rs-] ; 

num_f ree_cel 1 s=nuri_f r<^e_ce 1 1 s + 1 ; 

re tur n_l nbe 1 = r <■'; 

^o to s tr i n t r_n 1 1 oc; 
rd: 

ps eudo_l en^tb=ptr->5itrin' T _le^^t ^ ; 

inpu t_or_returr_str in^=su K str(ptr->strin^ / l / ^se'Hn_l 



i 1 d ; 



del et e_by_rrf no_enf': end; 

if 2*nun_f ree_cel 1 s > nun_entr!es t'-cn i^ to tr^^_r^'vj 

return; 



/•a**********************************/ 
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del ete_by_da tu~i: 

if dbd_lab_sv.< = Q t l .cn h o; 
dbd_lah_s>-/ = l; 
dbd_label (-1) =dV_l t_0; 
dbd_labrl (G ) =dbd_en_C ; 
db'Mabrl C!)=dbd_jTt_0; 
end; 
do i i = 1 to upper_bound; 

roturn_l abol =c!nl ete_by_da tu"\_retu rn ; 
p;o to datum_prol o":u n ; 
del ete_by_da tum_ro turn : 
SO to dbd_label (found); 

dbd_lt_0: dM_en_3: 
dsnwir.rs . roturn_ptr ( i i ) =ad'' r(nt_qua r t) ; 
ntccn t =dn ta__typc; 
"ntpon t=seT_ptr; 
r,o to do 1 rte__by_da ttin_f»n< r '; 



dbd_-t_0: 
If p tr-> f l ap: = Q then to to ''bd_pn_0; 
o.l se; 

Ptr->f lar=0; 

nu~i_en tr i rs=nun_r>ntr i cr.-l; 
nun_f ree_col 1 s=nu^frrr_col 1 r, + l ; 
return__l abol =dH ; 

CO to quart_alloc; 
dri: 
tent =ptr-> rrf no; 



i 1 d; 



del ctc_by_da turi_on ! : end; 

if 2*num_f rec_cc 1 1 s > niri_nn tr i es t*^cn to to trer_rebu 



re tu rn ; 



/a***********************************/ 
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rof n o_p r o 1 o ~ 1 1 o : 

if oxp = "r" t'rn nun r t_p t r =d_o r_q_o t r ( 1 ) ; 
c 1 lp quar t_:"> t r = d_o r_q_T t r ( i i ) ; 
1 1 rn_ i n t ~na x_l rri"t 1 "'; 



s en rc^_hy_rrf"o : 
turn, foun- J = " ; 

if f i r s t_on tr y =n'j 1 1 o t'~nn do; 
founH^- 1 ; 

'• o to rrtur n_ 1 n h r 1 ; 
ono; 
e 1 s o ptr = firs t_o n try; 

if exp = "r" t K on o r os on tor'_] oon_rr r no = quo r t_p roni r . 
q t e n t ( i i , c i ) ; 

else prrson tod_l oop_r o r po=quart. t r nt; 
1 as t_l eft, 1 as t_r i .^h t=nu M o; 
do i i i =1 to -H~jx_r'rp t^_of_t rcc; 

s to r o d_ 1 oo p_ r r f n r ~ p t r - > i t r r.i . r o f p o ; 

if prison to'l loon refno < stored loop refno t'irn 



do; 



do; 



no; 



if ptr->lptr~'-nullo t ,,r, n ^o; 
1 ns t_l of t = ptr; 
plicb=ptr->lptr; 
pt r = z 1 i c^ ; 
po to soa r r '"_Hy_ro f no_op-' ; 

o 1 s e do ; 

t 'j r n = 1 o f t ; 
po to re tu r n_l o Kr . 1 ; 
end ; 
end ; 
if prosmt ' 1 lpnn__r n fnn > s to r r,r '_l nop rofpo t'^er 

|r -)tr-) nt r^^nu 1 1 o t^r -' o ; 
lr;s t_r i ~'- t = pt r; 

r 1 i cdi =p t r-> r n t r ; 
p t r =r; 1 i c K ; 
po to s oa r c h_Hy_ref n o_on-' ; 
end ; 
c 1 s o do; 

t j r n = r i '~ h t ; 
po to r o tu rr,_ 1 a'.o 1 • 
onr! ; 
o n d ; 
if pr osrn tor'_l oop_rnf no = s to r o-'_l oon_rof no t^on 

f o u n d = 1 ; 

po to r o tur n_l ri'-io 1 ; 
c n r i ; 
s ea r cH_by_r of no_er M : err!; 
po to t r oc_r^')'j i 1 -'■ ; 



/if***********************************/ 
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da tum_prol ogue : 

str_ptr=dsm_ar^s . d_or_q_ptr( i i ) ; 
ml en_in t=Tinx_l on^t k ; 



s oa r oh_by_da tun: 
found, tu rn=0 ; 

if f i rs t_^r,try =nul To t h en ^o; 
f ound=-l ; 

no to roturn_J ab? 1 ; 
ond ; 
elso p t r = f i r s t_o n t r y ; 

prosented_loop_s trin"=su l )str( i npu t_o r_re tu rn_s tri n 
p;, 1, pseudo_l ength) ; 

last_lof t, last_ri«rbt=nul lo; 
do iil=l to nax_dopth_of_t mr; 

stored_l oon_str I n ^=substr(ptr->itorn. string !,otr 

->string_1en.f;th) ; 

if presented loop_strin<r < s torod_l oon_s t r i n«: t u 



en 



or. then 



nj- then do; 



less_t!an: do; 
if ptr-> 1ntr""=nu1 To t^en do; 
1 as t_l of t=ot r ; 
n; 1 icb=ptr->1ptr; 
ntr=r; lirh; 

,~n to so,-!ro>__hy__<'ia tun_end; 
end ; 
o 1 sf do; 

turn=loft; 

r: o to r o t u r n__ 1 a b p ] ; 

opd; 
o n J ; 
elso i ? r>rosont^''_l oop_s t r i n" > s tor«d_J ooo_s tr i 

f;rpatPr_t''or: dn; 

if ptr-> rptr _, =n , .j 1 1 o t'^on ''^; 
1 ast_r I ~><t=ptr ; 
n 1 icb=ptr->rptr; 
ptr=j;1 i ch; 
so to soarch_by_datun_ond; 

end; 
elso do; 

turn = r i r,h t; 
",o to rotu rn_l abel ; 
ond; 
end; 
else if prosnntod_l oop_s tr in"- = s torr d_l oop_s tr i 



f ounci=l ; 

r,o to rotu rn_l nb~l ; 
end; 
soarch_by_da turi_en' ! : end; 
r,o to troo_rnbui 1 d; 



■ * * * ■>: X * * ->■■ * i: * 



r t 






s I r I 



, * . ^ 



r r- t u r '" ' 



-■_.o rr.r 
i ) =str 



> t- r ; 



■tr) ; 



y r- : r- 



'■■■: S' 
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dsm into^er . ol 1 



05/01/70 1P.11.1 <Ht 



■ion 



dsrn_i nteger : proc ( dsn_a rr;s_pt r) ; 

del data_ses area (102U) based (scr_ptr); 

del first_off offset (data_se.e) based (se<-_ptr); 



del 1 dsm_args based (dsn_arts_ptr ) , 

2 upper_bounci fixed bin (17), 
c\ f i xeel bin ( 1 7) , 
op char (1)/ 
di char (1), 
e char (1), 
ddptr ptr, 

d_or_q_ptr (uppor_ bound) ptr, 
return_ptr ( ur>per_bound) ptr; 



del 1 type based (typc_ptr), 

2 dsm_nnmc char (32), 
2 data_type char (16); 



del 1 quart based (quart_ptr) / 

2 id fixed bin (35) initial (0), 

2 length fixed bin (35) initial (1), 

2 order fixed bin (35) initial (1), 

2 cent char (32), 

2 pent ptr, 

2 tent f i xed bin ( 35) ; 



ixed bin (35); 



dc 1 



1 qtent ( q l enn;th, norner; rixea nin i« 
1 nt_quart static, 

2 id fixed bin (35) initial (0), 
2 ntlensth fixed bin (35) initial (0), 
2 ntorder fixed bin (35) initial (1), 
2 intcent char (32), 
2 ntpent ptr; 

1 pseudo_s tr i nr;_array based (str_ptr), 
2 oseudo_l nnp:th fix^d bin (35), 

2 input_or_roturn_strinT c h ar (mlen_int); 
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del ( j j , 1 1 , nl en_i r, t, tmp, si r.n, si or, i , I i ) fix^-' Sin C^); 

del ell (12) chor (1) urr 1 i wn-l, 

cl 1 2 char (12) defined cll(l) una 1 i cr r-' ; 

del (qua rt_Dtr , s tr_ptr, suce_pt r, f's^_ar'*s_ptr, cor_pt r, s^~_nt r 
, t y p e_ p t r ) pointer; 
declare exp char(l) varyinq; 
del opcode char (1) varyinr; 

del dir char (IGF), onanr e^nr (32), ^mc^ fixed Hin (35), c 
ore fixed bin (17); 

del ( d i v i do, subs t r , nu 1 1 , addr ) builtin; 

del rem fixed bin (35) besed (con_ptr) / 
false char (k) based (con_ptr); 

del pot (C:ll) fixed bin (35) initial ( 1, 10 , 1 j , 1 00 , 12 " 2" , 1 

0,1000000,10200202, 

12 2 2 2 2 0,100002 TOO, 
1CC000 0000 0, 100202000222) static; 

**********/ 

oncode =dsn_a r ks . op ; 

sec,_pt r =ddpt r ; 

ty po_pt r = f i r s t_of f ; 

if opcode = "R" then °;o to <tp t_.ro 17 no; 

else if opcode = "n" t l, ^n ro to ":et_riatu ri ; 

else if opcode = "S M t h en ^n tn surcossor; 

else if opcode="N" t h en <^o to nev/_da to_ty pe; 
else i i = ; 

1 oop_2 : 

i i = i + ] ; 

ri s ;n_a r t s . r e t u r n_p t r ( i i ) = a d i r ( n t_q u a r t ) ; 
s er_p tr=ddptr; 
t y p e__p t r = f i r s t _o f f ; 
nit pen t =sor_P t r ; 
•■itcen t =da ta_ type ; 

if i i < u ppe r_bound t v, rn go to looo_2; 
r e tu r n; 



/••••♦••♦A************************************************** 
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successor: 








i i=0; 




1 oop. 


_3: 






1 i = i i 


i+1 




al loco t 




succ. 


_Pt 




succ. 


_Pt 




return_ 




if exp= 




el se 


qu 




succ_ 


_Pt 




succ. 


Dt 




if exp = 



i/Ci ) ; 



e quart sot (succ_ptr); 

r->cent=data_type; 

r-> pent=ser_pt r; 

ptr ( i i ) =succ_ptr; 

"E" then qunrt_ptr = d_or_q_ptrU) ; 

art_ptr=d_or_q_pt r( i i ) ; 

r -> con t=quart_ptr-> cent; 

r-> pen t = quart_pt r-> pent; 

"E" t h en succ_ptr-> tent=l+quart_ptr-> tent( i 



else succ_ntr-> ten t=l+quar t_pt r-> tent; 
if i i <uppcr_bound then ^o to loop_3; 
return; 



/•A********************************************************* 



get_da tum: 



on f i xedoverf 1 ow bn<rin; 

dsm_arr;s . mturn_ptr( i i ) =addr (nit_quar t) ; 

mtpent=se':_ptr; 

ntcen t = da ta_type; 

end; 

i i .= ; 
1 oop_7 : 

i i =i ; +1 ; 

if exp="F" t h en quart_ ptr=d_o r_q_pt r (1 ) ; 

else quar t_ptr=d_or_q_ptr( i i ) ; 

ml en_i nt = 12; 

allocate false set (con_ptr); 

allocate pseudo_s tr i n ff _arroy s"t (str_ptr); 

return_ptr ( i ? ) =s tr_r>t r; 

if exp="F" thnn tenn=qtcn t ( i i , c i ) ; 

else teTip = quart_pt r-> tent; 

if tonp < t^en <- ! o; 

si,°:ri=-]; 

temp=- te-np; 

end; 
el se si <rn = ] ; 
1=12; 
comp: 

rem=temp; 

temp=di vi de( temp, 11,35/0); 

rem = rem-10* temp; 

rem=rem+U£; /* A3H! conversion */ 

cll( i)=suhstr(false / U,l); 



th); 
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i = i - 1 ; 

if tcmp~'=0 then ~o to conp; 
if sir,n=-l then do; 

cll( i )="-"; 

1=1-1; 

end; 
pseudo_l enr;tb = 12- i ; 
input_or_return_str inn=substr(cl 12, I + 1, nseudo_l ?r» 

if i i <upper__bound tben ^o to loop_7; 

revert f i xcdoverf 1 ow; 

return; 



/******************•**********************************"****** 



f.ct_refno: 

ii=3; 
1 oop_0 : 

i i =i i +1; 

s t r_p t r =d_o r_q_p t r ( i i ) ; 

allocate quart set (qunrt_ptr); 

cent =c'a ta_type; 

pent =srn_ptr ; 

allocate rem set (con_ptr); 

return_ptr ( i i ) =quar t_pt r ; 

c!12=substr(i nr>ut_or_return_stri n-:, 1, ds^vj -'o_len^t^ 

if cl 1(1)="-" t k nn -'n; 

sloc=2; 

s i p-n=-l; 

end; 
else if cll(l)= M + " V^n do; 

sloc=2; 

s i °:n=l ; 

end; 



else do; 



si oc=l; 
s i rn=l ; 
e n :! ; 



loop 



te;np = ; 
rern = ; 
=s loc-1 ; 

= i+l; 
substr(false,U, 3)=cll(i); 
if ( rern<U8 | en> 5 7) thr>n do; 

ds<n_arp;s . return_ptr( i i ) =a-'dr (int_quart ) ; 

mtpent=ddptr; 

free quart_ptr->quart; 

go to en"!_of_5;r ; 

nnd; 
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temp=tomp+( ron-U P. ) *pot( pseuHq_len<>':t^-i); 
ond_of_sr : 

if i < pseudo_l ennth t^en ^o to loop; 

tent=temp*sircn; 

if ii < uppor_boun-! then r;o to loop_Q; 

return; 



/*********************************************************** 
**********/ 



n r v/_d a t a_t y p e : 

i i=0; 
1 1 1 looop: 

i i=i i + 1; 

cal 1 hcs_$fs_)5et_pnt^_nan^(se? r _ptr / di r,(!rec^,enanp 

, code) ; 

call arra_(102U / so^_ptr) ; 

al locate type set (typo_ptr) in ( da tc_se°:) ; 

da ta_type=ename; 

dsn_narne = "dsHi_i n te.^er"; 

if i i <uDper_boun'J then ^o to lllloooo; 

return; 



/•A********************************************************* 



end dsm I n te<?er ; 
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dsn_chai n. pi 1 



06/01/70 18^0.3 rHt 



4 on 



dsm_chain: proc (dsm_a rr:s_ptr ) ; 
/•♦•♦A****************************************************** 

del data_sep: area (102*0 base! (ser;_ptr); 

del 1 dsm_ai-RS based ( dsm_a rfrs_pt r) , 

2 upper_bound fixed bin (17), 

2 ci f i xed bin (17), 

2 op char (1), 

2 di char (1), 

2 r char (1), 

2 r^lptr ptr, 

- d_or_q_ptr ( upper_bour d) ptr, 

2 return_ptr (upper_bound) ptr; 



del 1 quart based (quar t_r>tr ), 

2 id fixed bin (35) initial (0), 
length fixed bin (35) initial (1), 
order fixed bin (35) initial (1), 
cent char (32) initial (data_ty~>e) , 
pent ptr initial (se«_ptr), 
ten t f i xed M n ( 35) ; 



del 1 quart_proper based (qua r t_pt r ) , 
2 qid fixed bin ("S5), 
2 qlenjrth fixed bin (35), 
2 qorder fixed Sin (35), 
2 qcent (qorder) char (32), 
2 qpent (qorder) ptr, 
2 qtent (ql enr-t^, qorder) fixed Sin (35); 

del 1 pseudo_s tr i nr_array based (str_ptr), 
2 pseudo_1 ensth fixed bin (35), 
2 input_or_return_strin.fr char (mlen_int); 



del 1 type based (typc_ptr), 

2 dsm_namc chnr (16) initial ( "dsn_cha i n") , 

2 data_type char (32), 

2 num_entries fixed bin (35), 

2 successor_chr> I n_head offset (data_so^), 

2 max_len^th fixed Sin (35), 

2 first_refne fixed bin (35); 
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be~ i n_dsm_cba i n : 

cxp=&SP\_ar;;s . r ; 
dor i = ds : n_arss . '■'. \ ; 
opcode =dsn_a r ! ;s.op; 
sc, p ,_ptr =ddptr ; 
t y p e_p t r = f i r s t__of f ; 



If opcode="D" then /* Inout is refnos */ 
if dori=" " then so to set_datum; 

else if dori="P" then no to Hnl r t^_by_re r no; 
else so to op_error; 



else if opco<-io= M R M then 



/* Hata strings are input */ 



if dori=" " then so to <rrt_refno; 
else if dori ="n" t^on "o to Hrl <->te_by_da tun; 
else if dori="l" t li en so to insert; 
else so to op_e rror; 

else if opcode="S" t^en 

if dori =" " then ro to successor; 
else go to op_error; 



else if opcode = "f'" then 

if (dor?-" " ft oxp = " ") then zo to nov/_da ta_ty pe; 



op_error: do i i = 1 to unprr_bound; 

return_ptr( i i ) =add r (mt_quar t ) ; 
mtcen t = da ta_typc; 
mtpen t=ses_pt r ; 
end; 
return; 

/•••••A***************************************************** 



n ew_d a t a_ t y p e : 

do ii = 1 to uppe r_hound; 

call arca_(102^ / so~_ptr) ; 

ca 1 1 hcs_$f s_set_pa t^_nane(ses_Pt r, di rra-ne,srecH 
, oname, code) ; 

allocate typr set (type_ptr) in (data_ses); 

num_entr ies = 0; 

call ioa__("what is nax lenrt^ for character stri 
ngs for " , a>"'a ?~7", subs tr( di rnane / 1, sr^ch) , enane) ; 

call read_l i st_(srech) ; 



end; 
return; 
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successor: 

do i i = 1 to uppor_bounH; 

return_label =successor_return; 
ko to refno_proloe:ue; 
successor_retu rn: 
return_lnbel =s_; 
go to quart_al loc; 
s_: 

if found=-l t k en 1 on^-t^O ; 

else If ptr=nul 1 t^en tent=suc 
ccssor_cha i n_hcad-> refno; 

else If ptr->succ=nu 
1 1 o then 1 enf;th=0 ; 

else tont=pt r->succ-> refno; 
enr!; 
ro turn; 






del cte_by_ref no: 

do i i =1 to upper_bound; 

return_label=dcl etr__by_re^no_return; 
go to rc?f no_prol o.ruc; 
de 1 ete_by_ref no_retu rn : 
if found" 3 ! tHpn do; 

return_ptr( i 1 ) =addr (mt_quar t ) ; 



else do; 



n teen t=data_ type ; 
ntpent=sef_pt r; 
end; 



r^tu rn__lab*>l =rd; 
no to strln»_al loc; 



rd: 

PSpuHp_1 en^t^ptr^ string 1 ppt 
th; 

? n pu t_o r_ r p t u r n_s trin<r=substr( 
ptr->string / l / ptr->strinp_lpnrtfO; 

if pred=null t h en succcssor_c^ 
a i n_hcad=ptr->succ; 

elsp prpd->succ=ptr->succ; 

f rop pt r-> i ten; 

num_entr ies s nur"_entr i es-1; 
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i nput_or_return_s tr I n.p, ], pscudo_J nn«rth) ; 



iDtr->strfnp;=substr( 
i otr->s tri n? lenr*t^ = 



pseudo_l enpth; 



end; 



iond: end; 



end; 



retu rn; 



/*********************************************************** 
******* ** */ 



quar t_a 1 loc: 

allocate quart sot (qua r t_pt-r) ; 

roturn_ptr ( i i ) =quart_ptr; 

pen t=soR_ptr; 

cent=da ta_t ype; 

go to return_l aSel ; 

s tr in£_al loc: 

Til en_i n t=max_l en^t^; 

allocate pseudo_s t r i n~_ar ray sot (str_ptr); 

ro turn_pt r ( i I ) =s t r_pt r; 

no to r n tu m_l ahol ; 



/****•****************************************************** 
**********/ 



rof no_pro 1 o,(;ue: 

if exp="F" t K cn quar t_pt r =d_or_n_ot r ( 1) ; 
else quar t_pt r=d_or_q_pt r( I I ) ; 

search_by_rrf no: 
found =0 ; 
If successnr_c!ini n_hrad=nu 1 1 o t'-en ^o; 

found =-1 ; 

zo to rctu rn_l a'^e 1 ; 

end; 
ptr =succcssor_cbai n_hcod; 
pred=nu 1 1 ; 

if exc = "r" t'inr presentnd_re-Fnn=q tent ( M ,c \ ) ; 
else prrscntc i_ref no=tont ; 
refno_l cop: 

if presen ted_refno>ptr->ref no t h en zn to refno_fut 



z; 



if presen ted_ref no < ptr->refno t^nn r^o; 

pt r=prod; 

r,o to rotu rn_label ; 

end; 
f ound=l ; 
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go to r nturn_f a')C l ; 
rcf no_fu tz: 
prcd=ptr ; 
gl i ch=ptr->succ; 
if glich=nu11o t'ion do; 

go to rotu rn_laS?l ; 

end; 
ptr=gl i ch; 
go to refno_l oop; 



da tum_pro1oguc: 

s t r_p t r = ri_o r_q_p t r ( I ! ) ; 

scorch_by_flotu"i; 
fourvi = 1 ; 

if succossor_c l> ai n_hrar'=nul 1 o t^cn *o; 
f ound=-l; 

go to roturn_l aSei ; 
end; 
ptr =successor_c'-.ai n_hoad; 
pred=nu 1 1 ; 

presen tor'_s tr ing=s , d u >st r ( i npu t_pr_retu rn_s tr i nn, 1, p 
soudo_l cngth ) ; 

da tun_l oop: 

i f prcsentcd__s tr i n::"'=sub,s tr(ptr->string, l,otr->str 
ing_length) then go to datur-i_futz; 
found=l; 

go to return_J abol ; 
da tum_futz: 
pred=ptr; 
gl ich=ptr->succ; 
if gl i ch=nul lo then do; 

go to rptu rn_l a^r 1 ; 
ond; 
p t r = g 1 i c h ; 
go to Ha tur,i_l oop; 



/*********************************************************** 
**********/ 



nnd dsm_chain; 
EOT 
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Mon 



dsn_tab 1 e. ol 1 



06/01/70 1758. 3 c*.t 



dsm_tablc: proc (dsrn_arrs_pt r ) ; 

/*********************************************************** 
*********/ 

del data_se,p; arra (aroa_sizo) based (sep_ptr); 

del 1 dsm_arr:s based ( dsn_ar ~s_pt r) , 

2 upper_bound fixed bin (17), 

2 ei fixed bin (17), 

2 op ehar (1), 

2 di char (1), 

2 e char (1), 

2 ddptr ptr, 

2 d_or_q_ptr (upper_bound) ptr, 

2 return_ptr ( uppor_bound ) ptr; 

del 1 quart based (quart_ptr), 

2 id fixed bin (35) initial (0), 

2 length fixed bin (35) initial (1), 

2 order fixed bin (35) initial (1), 

2 cent char (32) initial (data_type) / 

2 pent ptr initial (sep;_ptr), 

2 tent fixed bin (35); 

del 1 quart_proner based (quart_ptr), 
2 qid fixed bin (35), 
2 qleneth fixed bin (35), 
2 qorder fixed bin (35), 
2 qcent (qorder) c h ar (32), 
2 qpent (qorder) ptr, 

2 qtent ( q 1 en^t'" 1 , norder) fixed Mn (35); 
del 1 psoudo_strinf % _array based (str_ptr), 
2 pseudo_l en<* t^ fixed Sin (35), 
2 i n pu t_or_retu rn_s tr i nr rhar (Tiax_l enetH ) ; 

del 1 type based (type_ptr), 

2 dsm_name char (1G), 

2 data_type char (32), 

2 tab_off offset (data_sep;), 

2 num_entries fixed bin (35) initial (in__len), 
2 max_lenrth fixed hin (35) initial (in_max); 



del 1 table (in_len) based (tab_off), 

2 s tr i n^_l en^th fixed bin (35), 
2 string char (rnax_l en«;t h ) ; 
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dcl 1 mt_quart static, 

2 mtid ffxoH bin (35) Initial (0), 
2 mtleneth fixed bin (35) initial (0), 
2 mtorder fixed bin (35) initial (1), 
2 mtcent char (32), 
2 mtpent ptr; 

del presented string char (16H) vnryinr static; 

declare exp chaRl) varyinq; 

del (dirname char (16"), enamo r.'^ar (32), rrrr.^ fixed Mn (3 

5)) static; 

del (ses_Ptr, type_ptr, str_ptr, ouart_ptr) ptr static; 

del code fixed bin (17); 

del (aridr,di vi de, substr, max) bi.-iltin; 

del dsm_ar.^s_ptr ptr; 

del first_off offset (data_se.~) based (se"_ptr); 

del (, i i , tab_l en, in_l en, in_max, j j , area_s i ze, char_l en) fixed 
bin (35) s tati c; 

del return_label label ( r_, s_, d_); 

/************ it ********************************************* * 



bnri n_dsm_tab 1 e: 
seg_ptr=ddptr; 
type_ptr=f i rst_of f ; 

if substr (op, 1, 1) ="D" then ro to ^Pt_datu^; /* input i 
s refnos */ 

else if substr (op, 1, 1) ="H" t K on to to "■ot_rrf no; /* 
data strings arc input */ 

else if substr (op, 1, 1) ="5" t^en :n to successor; 
else if substr (op, 1, 1) =":"' t h m "o to nev;_Hata_type; 
else do ii =1 to uppor_bound; 

roturn_ptr ( i i ) =addr (mt_quar t) ; 
tntcent=""; 
mtpen t=ddp t r ; 
end; 
return; 



********/ 
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new_da ta_type: 

do i i = 1 to upper_bound; 

cal 1 hcs_0f s_?ct_path_naTi^(se-_ptr,-'i rna-nr, r.re. r.h 

, enar.ie, code ) ; 

call ioa_("what is the nun'ior of table entries in 
data type "a>"'a ?"7", subi.tr (d i rnoie, 1, «rcc, u ) , enano) ; 

call rcad_l i st_( in_len) ; 

call ioa_("what is nax lon^t*- for character strirr 
s in " , a>"'a ? "V", subst r (d i rna-rio, 1 , -roch) , enane) ; 

call read_l i s t_( i n_nax) ; 

arca_s i zp="iax( 102';, l';+in_len* (l+divide( in_nriax / H / 3! 



,0 + 1)); 



call arca_( arca_s i 7.o, se<-:_pt r) ; 
allocate typo# sr-t (tyoe_ptr) in (data_se^) ; 
allocate table set (tab_off) in (datr_SPf); 
num_en tr f cs=0 ; 

da ta_type=enane; 

dsn_nanie = "dsr.i_tabl e"; 

end ; 
return; 



/it********************************************************** 



get_da turn: 

do i i = 1 to upper_bound; 

if exp="E" then n=d_or_q_pt r ( 1) -> qtent ( i i , c? ) ; 
else n=d_or_q_ptr ( i i ) -> tent ; 

if ((m<=num_entr ies) * ( tahl e (rn) . st r i nO en":t , -" , =-l 
)) then do; 

return_ label =d_; 
go to str i ng_al loc; 

d_: 
pseudo_l en. frth = table(m). string length; 
input_or_return_str In^;=substr( taM eCm) . string, 1, 
pseudo_l ength) ; 

if di="D" then tabl e(m) . s t r i nr_l en°:th=-l ; 
end; 
el se do; 

dsm_arfrs. return_ptr( \ ? ) =add r(Tit_quart) ; 
rntcent=data_type; 
m t pen t =s e g_p t r ; 
end; 
end; 
return; 



/************************************/ 
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get_ref no: 

do i 1 = 1 to upper_bound; 

s t r_p t r =ri_o r_q_p t r ( I i ) ; 

presonted_s tr i np;=suSstr( i nou t_or_rpturn_ 
strinr, /I/ pseudo_1 enptb) ; 

do jj =1 to n'jn_entrips; 

if tablet j j ) . strl ne_l fn^t h " , =-l 
then 

if nresonted_s t r i np; = 
subs tr ( tabl e(j j ) . str i ng ; 1, taM p( j j ) . str i n.p;_1 en^th) t^pn p;o t 
o grq; 

end; 

if di="l" tben *o to insert; 



t_quart) ; 



i nsert: 



else do; 

dsn_ar°:s . return_pt r(ii)=adHr(nri 

mtr.ert=data_tyoe; 
mtpent =se^_pt r ; 
go to ?_end; 
end; 

num_entr i es=nun_entr i es + 1 ; 
tabl e(num_entri es).strin°:_len«: 
th=pseudo_l ength; 

tabl e(nu-n_entr ies) .string =subs 
tr( inpu t_or_return_str in<>;, l,pseudo_l en^th) ; 

j j =num_ent r i es ; 
tfrq: 

return_l ahel =r_; 
p;o to qunrt_alloc; 
r_: 

tent=j j ; 

if di="D" then tcM e ( j j ) . st r i n=:_l pn^t^=- 



1; 



i_cnd: end; 



return; 






successor: 



i/Ci ) ; 



do i i = 1 to upper_bound; 

if exp="F" t^en n=d_pr_q_pt r ( 1) ->qtent ( i 

else Ti = d_or_q_ptr( i i )-> tent; 
rpturn_l abo 1 =s_; 
e;o to qunr t_al loc; 



if m> nun_en t r i es I ti<0 tben do; 

retu rn_pt r ( i ? ) =addr (mt_quar t ) ; 
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freo qua r t_p t r-> quart ; 

•ntcent=data_type; 

mtpent=se?:_pt r ; 

£o to succ_erH; 

end; 
s loop: 
m=m+l; 

if rn>nu-i_en trios then l«np:th=0; 
if table(m) .stririf:_1on.frth=-l t^on *;o to 



s loop; 



ton t=m; 
succ_end: end; 
retu rn; 



/*********************************************************** 
**********/ 



guar t_a1 1 oc: 



:1 locate quort s^t (nuart_ptr); 
pent=ser,_pt r; 
cent=da ta_type; 
return_ptr ( i i ) =qunrt_pt r; 
go to return_labrl ; 



str in£_al Toe: 

allocate pseudo_s tr i nr:_array set (str_ptr); 
return_ptr ( i i ) =s tr_ptr; 
50 to r^turn_l abol ; 



/♦♦••A****************************************************** 



end dsm_table; 
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Wed 



rsn_wq. pi 1 



06/03/7u 101U.5 edt 



rsm_wq : procedure ( arg_pt r ) ; 

declare 1 args hased (arg_ptr), 
2 upper_bound fixed bin(35), 
2 op character ( 1 ), 



r, 



2 ql_Ptr 
2 rl_ptr 
/*Mot used here*/ 

2 q2_ptr 
2 r2_ptr 
used here*/ 

2 equiv_ntr 
/♦Not used here*/ 

2 return_arg 



(limit refer (upper_bound ) ) po 

(limit refer ( upper_bound ) ) po 

(limit refer ( upper_bound ) ) po 

(limit refer ( upper_bound ) ) po 



/♦Not 



(limit refer (upper_bound ) ) 
(limit refer (upper_bound ) 



i nter, 
i nter, 

i nter, 
i nter, 

po i n t e 

) po i n t 



er 



declare 1 quart based (Iptr), 



32) 
er , 
c order 



refer ( length ), al lo 
(rptr), 

(width)) char(32); 



2 ID fixed hin(35) initial (0), 

2 length fixed bin(35), 

2 order fixed bin(35), 

2 cent (al loc_order refer (order)) char( 

2 pent (al loc_order refer (order)) point 

2 tent(al loc_length 
refer (order)) fixed bin (35); 

declare 1 ent_vector based 

2 width fixed bin(35), 

2 names(al loc_order refer 
declare 1 i nt_sort_quar t, 

2 sid fixed bin(35) initial (0), 

2 slength fixed bin(35) initial(O), 

2 sorder fixed bin (35) Inl tlal (20), 

2 scent (sorder ) char(32); 
declare 1 feht based (eq_ptr), 

2 num fixed bin(35), 

2 newcent (1 refer (num)) char(32); 
declare return_place label (major_l oop, i n_n ! D_op, i 
n_P_op, i n_C_op_l, i n_C_op_2 ) ; 

declare op_label label (U I D_operate, S_operate, P_op 
erate, X_operate, Z_operate, M_operate, 

E_operate, n_operate, 0_oper 

ate, C_operate); 

declare q_alloc_r label (q_a 1 1 oc_l, q_al 1 oc_2, q_al 1 
oc_3,q_al loc_i*,q_al loc_5,q_al loc_6,q_al loc_7,q_al loc_8); 



dec 1 are (gen_purpose_ptr, nev/_ptr, f ree_ptr , eq_pt r, t 

ptr,cptr) pointer; 

declare ( 1 ptr, rptr, temp_ptr, temp2_ptr, temp_l ptr, te 

mp_rpt r ) po i n ter ; 

declare (null, max) builtin; 
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declare cor res ( s 1 ength ) fixed b!n(35) based (gen_p 
urpose_ptr ) ; 

declare token ( s 1 ength ) fixed bin(35) based (e;en_pu 
rpose_ptr ) ; 

declare int_cent(20) char(32); 

declare a 1 loc_cent ( 20 ) char(32); 

declare cent_f 1 ag(20 ) fixed initial((20) 0); 



declare temp fixed bin(35); 
declare (n_sv;,no_sort_sw) fixed bin (1); 
declare (step_sw) fixed bin(l) initial (Ob); 
decl are (1 pi ace, rplace / opl ace, tpl ace, al loc_order, a 
1 loc_length, ent ry_count ) fixed bin(17); 

declare (slength, r row, rcol , 1 row , 1 col ,nc,nr,cl, 1 t, r 

t, f ree_Jen, f ree_ord ) fixed bin(17); 

declare (ii,jj,kk,ll,mm,i,j,limit,ocount,place,chu 
nk) fixed hin(17); 

declare ( 1 length, rlength, 1 order, r order , l_new_order 
) fixed bin(17); 



if args.op="U"|args.op="l " | args .op="D" then op_lab 
el =U I D_operate; 

if args.op="P" then op_l abel =P_operate; 



if args.op="X" 
if args.op="0" 
it args.op="C" 



if args.op="S" then op_l abel =S_opera te; 

then op_l abel =X_operate; 

then op_l abel =0_operate; 

then op_label =C_operate; 
if args.op="E" then op_l abel =E_operate; 
if args.op="M" then op_l abel =f'_operate; 
if args.op="Z" then op_l abel =7_opera te; 
if args.op="0 M then op_l abel =Q_operate; 



do kk = l to args. upper_bound; 

if args.op = "l'"|args.op = "l " | args ,op= M D" then go to 
no_set_ptrs; 

1 ptr =args ( kk ) .ql_ptr ; 

rptr=nrgs(kk). q2_pt r ; 
no_set_ptr s : 

return_pl ace=major_l oop; 

go to op_l abel ; 



quart_alloc: allocate quart set (temp_ptr); 
go to q_al loc_r; 



E_operate: al 1 oc_order=order ; 

allocate ent_voctor set (args ( kk ). return_arg ) ; 
do i=l to alloc_order; 

args (kk) . return_arg- >nanes (i)=cent(i); 
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o n d ; 

ro to r o tu rn_p 1 ace ; 



Z_nperate: a r ,\ s ( k k ) . r e t u r n_a r <^ = 1 p t r ; 
do i ~ ] to order; 



ppnt( i )-nul 1 ; 



err 



^o to re t urn_pl ace; 



i',_operate : ar^s ( kk ) . return_ar^ = l pt r ; 
if width" , = ordei' then do; 

cal 1 rs_error?pr( 103, ""i", 1 otr, rntr ); 

a r s s . retur n_a r p, ( k k ) = n u 1 1 ; 

eo to re tu rn_p 1 ace ; 
end; 
do i = 1 to order ; 

if names ( i )- = "V' then cent ( i ) =names ( i ) ; 

o n d ; 

^o to re t ur n_nl ace ; 



0_operate: if w i d t h"" = or Her then do; 

cal 1 CS_error$pr( 10 3, "0", 1 pt r , r pt r ) ; 
nul l_answer : args.re tur n_ar^ ( kk ) =nu 1 1 ; 
?,o to re turn_pl ace ; 
end ; 

slene;th=orHer; 
al 1 o c_o r H e r = s 1 e n r; t h ; 
allocate ent_vector set(cptr); 
allocate token set(tptr); 

do rii'i-- 1 to order; 

if names (mm ) = ".»," then cp t r- >n Barnes (mm ) =con t (rrn ) 



else cptr-^namesC mm )=names( mil ) ; 
if names (mm )"' = " " then do; 
tptr->token(jj ) =mn ; 

end; 
end ; 

if j j > 1 then a 1 1 oc_or der =j j - 1 ; 
else p;o to null_answer; 
al 1 o c_ 1 e n e, t h = 1 e n .^ t h ; 
n_a 1 loc_r=o_al loc_7; 
^o to auar t_a 1 1 oc; 
q_a 1 1 o c_ 7:tplace = l; 

do mm=l to alloc_order; 

tenp_ptr-)cent ('am ) =cpt r- > names (tptr->token(mn) 

); 

t emp_pt r - > pen t ( nn ) =nu 1 1 ; 
end ; 
do j j = 1 to length; 

p sv' = 0h; 
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if tent ( lplace,opiace >>rptr->tenEi rpiace,optac 

e) then do; 

if arr;s.op = "U" then do; 

do ocount=l to alloc_order; 

temp_ptr->tent (tplace / ocount)=rptr 
->tent(rp1ace / ocount); 

end; 

tpl ace=tp1 ace+1; 
end; 

if rptr->length>rpl ace then do; 
rplace-rpl ace+1; 
go to neworder; 
end; 

else finish_left: do pi ace = l pi ace to lengt 
h whMe(args.op = ,, U M |args.op="D M ); 

do ocount=l to a11oc_order; 

temp_ptr->tent ( tpl ace,ocount )=tent 
( 1 pi ace,ocount ); 

end; 

tpl ace=tpl ace+1; 
end; 

go to stop_action; 
end; 
else do; 

if args.op="U l, |args.op=• , D ,, then do; 
do ocount=l to alloc_order; 

temp_ptr->tent (tpl ace,ocount )=tent 
( 1 pi ace,ocount ) ; 

end; 

tplace=tplace+l; 
end; 

if 1 ength>l pi ace then do; 
1 place=l place+1; 
go to neworder; 
end; 

else f ini sh_r i ght : do place s rplace to rptr 
->length whi le(args.op= M U M ); 

do ocount=l to alloc_order; 

temp_ptr->tent (tpl ace / ocount )=rptr 
->tent(rpl ace,ocourit ); 

end; 

tpl ace=tpl ace+1; 
end; 

^o to stop_action; 
end; 
end; 
else do; 

if order>oplace then do; 
opl ace=opl ace+1; 
go to check; 
end; 

if args.on="D" then go to nocopy_ri ght ; 
do ocount=l to alloc_order; 

temp_ptr->tent ( tpl ace,ocount ^tentdplace, 
ocount ); 



nocopy_r ight 



left; 
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end; 

tpl ace=tpl ace+ 1; 
if 1 ength~'> 1 pi ace then do; 

if rptr- > 1 ength>rpl ace then do; 
rpl ace=rpl ace+ 1; 
go to f i n i sh_r i gh t ; 
end; 

else go to stop_action; 
end; 
else do; 

1 pi ace = l pi ace+1; 

if rptr-> 1 ength~">rpl ace then go to 

rpl ace=rpl ace+1; 
go to neworder; 
end; 



finish 



end; 
stop_act ion: opl a ce = a 1 1 oc_ length; 

a 1 loc_length = tplace-l; 

if al 1 oc_1 ength=opl ace then go to no_nevv_copy; 

temp2_r>tr = temp_pt r ; 

q_a 1 1 oc_r =q_a 1 1 oc_2 ; 

go to quart_alloc; 
q_alloc_2: 1o jj=l to alloc_order; 

te-ip_ptr->cent ( j j )=cent(jj ); 
te;ip_ptr->pent ( j j )=pent ( j j ) ; 



J); 



nm = l to al loc_l ength; 
temp_ptr->tent (mm, j j ) = temp2_pt r- > tent (mm, j 



end; 
end; 

al loc_length=oplace; 
free temp2_ptr- >quar t ; 
no_new_copy :args (kk ) . return_arg= temp_pt r ; 
go to return_pl ace; 



P_operate: if rptr=null then go to ge t_f i r s t_el ement ; 

if rpt r-> 1 ength=0 then go to get_f i rst_el ement ; 
al 1 oc_ordf>r =order ; 
slength=al loc_order; 

if rpt r- >order~'=a 1 1 oc_order then do; 
args. return_arg(kk ) =nul 1 ; 
cal 1 GS_e rror$pr( 101 / op / lptr / rntr); 
go to return_pl ace; 
end; 

allocate corres set (cptr); 
do Ii=l to alloc_order; 

do j j = 1 to alloc_order; 

if rptr->cent ( j j )=cent ( i i ) then do; 

cptr->corres( \ i )=rptr->tent(l,jj ); 
go to next_step_on; 
end ; 
end; 
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C_operate : 

eq_ptr=equi v_ptr (kk) ; 

1 1ength=lptr->length; 

rlength=rptr->length; 

rorder=rptr->order; 

lorder=lptr->order; 

if ( lorder+rorder )"'=feht.num then 

cal 1 GS_error$p(105,"C",eq_ptr,nul 1 ); 



/* 1. put new bindings in int_cent */ 

do i = 1 to lorder; 

if nev/cent(f )-"A" then int_cent ( i ) = 1 ptr->cent ( 

i); 

else int_cent ( i )=newcent ( i ) ; 

end; 
do j = 1 to rorder; 

if newcent ( lorder+j )="&" then i nt_cent ( lorder+ 
j ) = rptr->cent(j ); 

else int_cent ( lorder+j )=newcent ( lorder+j ); 

end; 

/* 2. sort left quart on cents in domain of lambda (see thes 
is) */ 

lsort: k=l; 

sor ler = l order; 
do i =1 to lorder; 

if cent_fl ag( i )=1 | int_cent ( i )=" " then go to 1 
nof i 1 1 ; 

do m=lorder+l to lorder+rorder; 

if ? nt_cent (m)=int_cent ( i ) then do; 
cent_f lag( i )=1; 
scent (k)=l ptr->cent( i ); 
k=k+l; 

go to jtest; 
end; 
end; 

go to 1 nof i 1 1 ; 
jtest: do j=i+l to lorder; 

if int_cent( i )=int_cent ( j ) then do; 
cent_f 1 ag(j )=1; 
scent (k )=1 ptr->cent (j ); 
k=k+l; 
end; 
end; 
1 nof ill: end; 
contin: do i = 1 to (lorder-1); 
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1 iend; 



if cent_flag(i) = 1 1 int_cent ( i ) 



_n ii 



then go to 



cent( j ) then do; 



cent_f 1 ag( i )=1; 
scent (k) = l ptr->cent( i ) 
k-k+1; 

do j = (i+1) to lorder, 
if int_cent( i ) = int_ 
cent_flag(j )»1; 
scent (k)=l ptr->cent ( j ) ; 
k=k*l; 
end; 
1 iend: end; 

do i=l to lorder; 

if cent_flag(i )=0 then do; 
cent_f lag( i )=1; 
scent(k)=lptr->cent(i ); 
k=k+l; 
end; 
end; 

rptr=addr ( int_sort_quart ) ; 
return_p1 acci n_C_op_l; 
go to S_operate; 
in_C_op_l: f.emp_ptr = return_arg(kk); 
tenp_l ptr=temp_ptr ; 
rptr*q2_ptr(kk); 
do i = 1 to lorder; 

do j = 1 to lorder; 

if temp_ptr->cent(i )=1 ptr->cent ( j ) then 

temp_ptr->cent(i )=int_cent( i ); 
end; 
end; 

/* 3. check right quart for need to sort */ 
rsort : 

k-1; 

sorder = ror ler; 

rptr=q2_ptr (kk); 

do i = lorder+1 to lorder+ rorder ; 

if cent_flag(f)=l| int_cent(i )=" " then go to r 



nof i 1 1 ; 



do j=l to lorder; 

if int_cent( i )=int_cent(j ) then do; 
cent_f 1 ag( i )=1; 

scent (k)=rptr->cent( i -lorder ); 
k = k+l; 

go to mtest; 
end; 
end; 
go to rnof i 1 1 ; 



mtest 



rnof i 1 1 



no m=i + i to r"mrrer+ lor-.'er; 

if int_cent(i )=int_cent(m) then do; 
cent_f lag(n)=l; 
seen t(k)=rptr->cent(m-l order); 

k=k+l; 
end ; 

end; 



end ; 



iend; 



rlend: 



in C op_2 



then 



do i = (lorder+1) to ( lorder+ rorder ) ; 

if cent_flag(i )=1 | i nt_cent ( i ) = " " then so to r 

cent_f lag( i )=1; 

scent (k)=rptr->cent(?-lorder); 

k=k+l; 

do m=i + l to 1 order* rorder; 

if int_cent('n) = ?nt_cent ( i ) then do; 

cent_f lag(m)=l; 

scent (k)=rptr->cent(m-l order ); 

k=k+l; 
end; 
end; 
end; 

do i=l+lorder to lorder+rorder ; 
if cent_f 1ag( i ) = then do; 

cent_f lag( i )»1; 

scent (k)=rptr->cent( i-lorder ); 

k-k+1; 

end; 

end; 

lptr=rptr; 

rptr=addr ( i nt_sort_quar t ) ; 
return_pl ace=in_C_op_2; 
go to S_operate; 
temp_ptr=return_arg(kk); 
rptr=q2_ptr(kk); 
1 ptr=temp_l ptr; 
do i = i to rorner; 

do j = (lorder+1) to (lorder+rorder); 

i f temp_ptr->cent (i ) = rptr->cent(j-lorder) 



end; 



end; 



rptr->cent (j-lorder ) = int_cent(j); 



o al i end; 



al loc_order =1; 

do i = 1 to (lorder-1); 

if 1 ptr->cent ( i )=1 ptr->cent ( i +1) then go t 

else if lptr->cent(i )--" " then do; 

al loc_cent (al loc_order )=lptr->cent(i ); 
al loc_order=al loc_order+l; 



en 



o a r i e n d ; 

o a r i e n d ; 



en 



q_al loc_8 : 



begi n_compose 
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end; 
al iend : end; 
if Iptr->cent ( lorder-1 )~'=1 ptr->cent ( lorder ) th 

if 1 ptr->cent( lorder )"=" " then do; 

al loc_cent (al loc_order )=lptr->cent( lorder) 

al loc_order=a1 loc_order+l; 
end; 
l_new_order =al loc_order-l ; 

do i = 1 to (rorder-1); 

do j = 1 to l_new_order; 

if al loc_cent ( j )=rptr->cent ( i ) then go t 

end; 
if rptr->cent ( i )=rptr->cent ( i +1) then go t 

else if rptr->cent( i )"' = " " then do; 

al loc_cent (al 1 oc_o rder ) = rptr->cent(i ); 
al loc_order=al loc_order+l; 
end; 
ariend: end; 
if rptr->cent( rorder )~' s »rptr->cent ( rorder-1 ) th 

if rptr->cent (rorder )"■=" " then do; 

al loc_cent (al loc_order )=rptr->cent( rorder) 

al loc_order=al loc_order+ 1; 

end; 
al loc_order = al loc_order-l; 
al 1 oc_length=rl ength*l length; 
temp_rpt r = temp_pt r ; 
q_a 1 1 oc_r =q_a 1 1 oc_8 ; 
go to quart_alloc; 

new_ptr=temp_ptr ; 
do i = 1 to alloc_prder; 

new_ptr->cent ( i )=al 1 oc_cent ( i ) ; 

end; 
io i = 1 to lorder; 

if rptr->cent( 1)=1 ptr->cent( i ) then cl =i; 

end; 



1 row, rrow, nr = l; 
row_i nc r : 

if 1 row) 1 1 ength | rrow>r 1 ength then do; 

n r = n r - 1 ; 

go to return_sequence; 

end ; 
if 1 ptr->tent ( 1 row,cl Xrptr- > tent ( rrow, 1) then do; 
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1 row=l row+ 1; 
go to row_incr; 
end; 
if 1 ptr->tent( 1 row, cl )> rptr- > tent ( r row, 1) then do; 

rrow=rrow+ 1 ; 
go to row_incr; 
end; 



one_compose : 

1 col , rcol , nc = l; 
1 r_comp : 

if 1 ptr->cent(lcol )" , = rptr->cent ( rcol )|lptr->cent(l 

col ) = " " then do; 

lcol_incr_0 : 
lcol =lcol +1; 
if 1 col >lorder then do; 

new_pt r-> tent (nr,nc) = lptr-> tent (1 row, 1 col - 



l); 



ncr_0; 

en 

col-1) then 



nc=nc+ 1; 

go to r i ght_f i ni sh; 
end; 
else if lptr->cent(lcol ) = " " then go to lcol_i 

else if lptr->cent(lcol ) = 1 ptr->cent ( 1 col -1 ) th 

if lptr->tent(l row, lcol ) = 1 ptr->tent( 1 row, 1 

go to lcol_incr_0; 
else do; 

1 row=l row+ 1; 
go to row_incr; 
end ; 
else do; 

new_ptr->tent (nr,nc)=l otr->tent(l row, 1 col- 



1); 



nc=nc+l; 

go to lr_comp; 

end; 
end; 
else if lcol>=lorder then do; 
lcol =lcol+l; 

if lptr->tent(l row, lcol -1 )-=rpt r- > tent ( r row, re 
ol ) then go to r i gh t_f i n i sh ; 
else do; 

new_ptr->tent (nr,nc) = lptr->tent(l row, 1 col - 

l); 

nc=nc+ 1; 

^o to r i ght_f i ni sh ; 
end; 
end; 
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else if lptr->cent(lcol )=1 ptr->cent ( lcol +1) then 
If 1ptr->tent( 1 row, 1 col )"=1 ptr->tent ( 1 row, lcol 
+1) then do; 

1 rov/ = l row+ 1; 
go to row_incr; 
end; 
else do; 

lcol =1 co 1+1; 
go to 1 r_comp; 
end; 
else if rcol>=rorder then do; 
rcol =rcol +1; 

if lptr->tent(l row, lcol )-=rptr->tent ( r row, rcol 
-1) then go to left_finish; 
else do; 

new_p t r- > ten t ( nr, nc ) =rptr-> tent (r row, rcol - 

1); 

nc=nc+ 1; 

go to left_finish; 
end; 
end; 
else if lptr->tent( 1 row, lcol )-=rptr->tent (rrow, rco 
1 ) then do; 

if lptr->tent ( 1 row,cl ) < rptr->tent ( rrow, 1 ) th 
en rrow=rrow+l; 

else lrow=lrow+l; 
go to row_incr; 
end; 
else do; 

new_ptr->tent (nr, nc ) = 1 ptr->tent ( 1 row, lcol ); 

lcol =1 col + 1; 

rcol =rcol +1; 

nc=nc+l; 

go to lr_comp; 

end; 



right_f ini sh : 

if rcol>rorder then do; 
nr=nr+l; 

if lptr->tent(l row,cl) < rptr->tent ( rrow, 1 ) th 
en rrow=rrow+ 1; 

el se 1 row=l row+1; 
go to row_incr; 
end; 
else if rptr->cent (rcol )=" " then do; 
rcol =rcol +1; 
go to r i ght_f ini sh; 
end; 

else if rptr->cent( rcol )=rptr->cent (rcol +1) then 
if rptr-> tent (rrow, rcol )=rptr->tent (rrow, rcol + 
1) then do; 

rcol =rcol+l; 

go to r ight_f ini sh; 
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end; 

else do; 

if 1 ptr->tent( 1 row,cl) < rptr->tent ( rrow, 1 

) then rrow-rrow+1; 

el se 1 row=l row+1; 

go to row_incr; 

end; 
else do; 

new_ptr->tent (nr,nc)=rptr->tent( rrovi, rcol ); 

nc=nc+l; 

rcol =rcol+ 1; 

go to r i ght_f i ni sh; 

end; 



lef t_f i ni sh : 

if lcol>lorder then do; 
nr=nr+l; 

if 1 ptr->tent( 1 row,cl) < rptr->tent ( rrow, 1 ) th 
en rrow=rrow+l; 

else 1 row» 1 row+1; 
go to row_incr; 
end; 
else if lptr->cent(lcol )■" " then do; 
lcol =lcol +1; 
go to 1eft_finish; 
end; 

else if lptr->cent(lcol ) = 1 pt r->cent ( lcol + 1 ) then 
if lptr->tent(l row, lcol ) = 1 ptr-> tent ( 1 row, lcol + 
1) then do; 

lcol =lcol +1; 
go to left_finish; 
end; 
else do; 

1 row = l rov;+ 1; 
go to row_incr; 
end; 
else do; 

new_ptr->tent(nr,nc)=l ptr->tent(l row, 1 col ); 

nc=nc+l; 

lcol =1 co 1+1; 

go to lef t__f Ini sh; 

end; 



tplace=nr-l; 
free temp_l ptr->quart ; 
free temp_rptr->quart ; 
return_pl ace=major_l oop; 
go to stop_action; 
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S__operate: si ength=length; 

if rptr=null then go to skip_l; 
if order^rpt r->order then do; 
args (kk ) . return_ar? ) = nul 1 ; 
call GS_error$pr ( 101 / op / lptr,rptr); 
go to return_ol ace; 
end; 
/♦Error here is unequal orders in sort*/ 
skip_l: al 1 oc_l ength=l ength; 
al Too_order=order ; 
no_sort_sw=lb ; 
allocate token set (tptr); 
allocate corres set (cptr); 
i f rptr=nul 1 then do; 

do ii=l to alloc_order; 

corres ( 1 i ) = i f ; 
end; 

go to ski p_2 ; 
end; 
do i i =1 to alloc_order; 

do jj=l to alloc_order; 

if rptr->cent ( N )=cent( j j ) then do; 
cptr->corres(i ! )=jj; 
if ii"'=jj then no_sort_sw = 0b; 
go to one_corres_down ; 
end; 
end; 
args (kk ) . return_arg=nul 1 ; 
free cpt r- >cor res ; 
free tptr->token; 

cal 1 'lS_error$pr (102,op,lptr,rptr); 
go to return_pl ace; 
/♦Error here is inconsistant entries in the two cent tuples* 

/ 

one_cor res_down : end; 

/♦Set up the tptr-> tokens*/ 
skip_2: do ii=l to al 1 oc_l ength; 
tptr->token( i i ) = i i ; 
end ; 
/♦Main sort*/ 

if no_sort_sw then go to sort_done; 
do iT=l to al loc_length; 

do jj=l to (al loc_length-l); 
n_sw=0; 
do mn=l to alloc_order; 

if tent ( tptr->token(j j ) / cptr->corres (m 
m) )> = tent ( tptr->token( j j + 1 ), cpt r- >cor res (mm) ) then do; 

temp=tptr-> token (jj+1); 
tptr->token(jj+l)=tptr->token(jj); 

tptr->token( j j )=temp; 

n_sw=l; 

go to pop_extra_l oop; 
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end; 
end; 
pop_extra_loop: end; 

if n_sw=0 then go to sort_done; 
end; 
sort_Jone : q_al loc_r=q_al loc_U; 

,<*o to quart_alloc; 
q_alloc_i*: do i i =1 to alloc_order; 

temp_ptr->cent( i i )=cent (cptr->corres ( i! ) ); 
temp_ptr->pent( i ! )=pent (cptr->corres ( i i ) ); 
# do jj=l to al loc_1ength; 

temp_ptr->tent(jj, i i )=tent (tptr->token( j j ) 
/ cptr->corres( I i ) ); 
end; 
end; 

free tptr->token; 
free cptr->corres; 
args(kk ) . return_arg=temp_ptr; 
go to return_place; 



major_loop: end; 

return; 
error: end; 

rr\c 
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<w> rsn_q. pi 1 



00/02/70 2035. 7 edt 



Tur 



rsm q : 



refer (order)) 



procedure (arnotr) ; 
declare 1 nr.^s based (ar^ptr), 
2 bound fixed Sin(35) / 
op chard), 

qlptr (limit refer (bound)) poin 
rlptr (limit refer (bound)) poin 
q2ptr (limit refer (bound)) poin 
r2ptr (limit refer (hound)) poin 
eptr (limit refer (bound)) point 
2 retptr (limit refrr (bound)) poi 
declare mgr$cq entry external returns( 
declare 1 quart based (quart_ptr), 
ID fixed b!n(3 r O initial(O), 
length fixed Mn(3r>), 
order fixed bin(3D, 
cent (al loc_order refrr (order)) 
pen t( a 1 1 oc_orde r refr»r (or^'^r)) 
tent(al loc_l enr:t^ rofor (lon^t*") 
f i xed b i n ( 3 5 ) ; 
declare oset hi t ( If?) based (^en_pum^s 
declare new area area (ar^a siz^) base 



ter, 

ter, 

tor, 

ter, 

er, 

nter; 

poi nt°r) ; 



)); 

); 

)); 



declare old_arca area (arcn_sizo) base 
declare old_area2 area (area_size) has 



cbar(32), 

Doint^r, 

, al 1 or_o r'-'^r 

e_p t r ) ; 

d (rrtptr(kk 

d (rlptr(kk) 

ed (r2ptr(kk 



declare 1 header based (hdr_ptr), 

2 rsn_namo char (15), 

2 nar,ie_r char (32), 

2 quart location offset (old_area) 
dec 1 are (alToc_l enr:th, al 1 oc_ordr.r, ar^a, 

1 imi t,mm) f i xed bin (17); 

declare (arp;ptr,r:en_pu rnose_pt r, *v!r_pt 
t r ,qua r t_ptr ,use) pointer; 



_size,jj, !k, 
r, new_a r°-s_p 



if op = "H" then t;o to no_ca 1 1 ; 

1 i n i t = b o u n d ; 

allocate ar^s set (new_ar ^s_pt r ) ; 

new_a rr;s_pt r-> op =op; 

if op="R" then do; 

do kk = l to limit; 

if qlptr(kl:)~'=nul 1 t'^en n^v.'_a r^s_pt r-> ret r 
tr(kk)=qlptr(kk) ; 

else if addrcK r]ptr(kk), rlpt r( kk) ->osct) - 
> rsm_name~'= ,, rsrn_q" then do; 

ncw_arr;s_ptr->retet r (k!-) =n^r$cq(rlptr( 
!;k)) ; 



find; 
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el se nev;_arr;3_ptr->r^tptr(kk)=addrcl (rlptr 
( kk), rlptr (kk )->osot) ->quart_l neat ton; 
end; 

CO to no_ca 1 1 ; 
end; 
do kk=l to linit; 

if qlptr (kk)"-=nu11 tHen do; 

no w_a r ks_p tr->qlptr(kk)=qlptr(kk); 
end ; 
if q2ptr(kk)" , =nul 1 t'-on do; 

nevv_arp:5_ptr->q2ntr (kk)=q2ntr(kk) ; 



pne! ; 

if rlptr(kk)" , =nul 1 t u rr do; 

n ew_a r ts_p tr->qlptr(kk)=po'nter(addrpl(rlp 
tr( kk), rlptr(kk)->oset)->quart_locatio->,ol ^arr-n) ; 
end ; 
if r2ptr( kk)"=null tJ en -*o; 

if addrol(r2ptr(k!:), r2^tr(k!-)->os^t)->rs^_ 

nar,ie" = "rsM_q" tHon 

n ew_a r h; s_p t r - > q 2 o t r ( k k ) =m °; r '■ c q ( r 2 o t r ( k 

k)); 

el se nev;_ar< i :s_ptr->q2ntr (kk) =poi n ter (ad ^ r 1 - 
1 (r2ptr(kk) / r2pt r( kk) ->ose t) ->quart_l or at i or, ol d_area n ) ; 
end; 

n evv_a r *;s_p tr->rlptr(kk.) / n ew_a r ^s_p t r-> r 2 n t r ( k k 
) , new_arr,s_ptr-> r etptr ( kk) =nu 1 1 ; 

now_arr:s_ptr->optr (kk) =eptr (kk) ; 
end; 

call r s m_w q ( n ev/_a r r s_p t r ) ; 
no_call: do kk = l to lirit; 

q u a r t_p tr i n ew_a r <t s_p tr->retptr(kk); 
arca_s i ze = di vi de( quar t_pt r-> 1 en^t^*quar t_pt r-> 
order+1050 / 102'* / 17,C)*lC2U; 

cal 1 area_(arca_s i ze, retptr( kk) ) ; 
allocate header in (new_area); 
rsm_name="rsni_q"; 
if op = "M" then fro to ski nit; 
al 1 oc_l ength=quart_pt r-> 1 en~t^; 
al loc_order=quart_ptr-> order; 
allocate quart set (use) in (nev/_area); 
a-idrel ( retptr(kk), retptr(kk) ->oset) ->quart_loc 
ation=offset(use, new_a rea) ; 

do j j = 1 to alloe_ord^r; 

use-)efnt(jj) =qua rt_pt r->c^nt ( j j ) ; 
use-> pent( j j ) =quar t_pt r-> pr>nt( j j ) ; 
do m = l to a 1 1 oc_l on^t u ; 

usc-> tont(nn, j j ) =qua rt_ptr-> tent (tip, jj 



); 



ski p i t; 



end; 

end; 

if op-^'R" then free quart_pt r->quart ; 
end; 

free new_arr;s_pt r->arrs ; 
end; 
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<s>tree.pll OC/02/70 1 2 •'» U . edt 



Tuc 



PRELIMINARY VERSION 

trce_rcs tructurc: procedure ( dsr'_ar^s_ptrO ; 

del data_seg area (area_size) based (se^_ptr); 

del 1 quart based (quart_ptr) , 

2 id fixed binary (35) initial(O), 

2 length fixed bin (35), 

2 order fixed bin (35) initiaH2) / 

2 cent (2) char (32) , 

2 pent (2) ptr, 

2 tent (ai 1oc_lenTt !i refer (length), 2) fixed b i n (35 



); 



del 1 dsrn_ar~s based (dsn_arts_pt r) , 

2 upper_bound fixe- 4 binary (35) initial(l), 

2 op char (1) ini tin! ("""), 

2 di char (1) initial ( " "), 

2 e char (1) ini tial ( M "), 

2 d_o r_q_p t r p t r , 

2 ddptr ptr, 

2 return_ptr ptr; 

del 1 type based (type_ptr) , 

2 dsm_name chart 1G), 
2 data_type char ( h ) , 

2 num_f ree_cel 1 s fixed bin (35), 

2 nunv_entr i es fixed bin (35), 

2 max_l en?:th fixed bin (35), 

2 f?rst_entry offset (data_se<r), 

2 succes sor_c h ai n_hoad offset (data_sef); 

del 1 item based (intr) , 

2 lptr offset (data_se<0, 
2 rptr offset ( data_se*) , 
2 succ offset (data_se<r), 
2 flan fixed binary (35), 
2 refno fixed bin (35), 
2 s tr i nn_s tructure, 

3 s tr i n^_l en^tb fixed binary (35), 
3 string character (nax_l en«rth) ; 

del 1 area_fake based (fake_ptr), 

2 first_off bit (1C) unaligned, 
2 tprewq_fake bit (IS) unaligned, 
2 curr_len bit (13) unalir;npH, 
2 qeeudm_fake bit (18) unaligned, 
2 next_offset bit (18) unaligned; 
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declare (new_ptr, xf er, ncw_hc!r ) pointer; 
declare ( next, tenp_of f sot) offset (dflt?_srO; 
declare ( new_i ton_of f sot, 1 ns t_nrw_i tem_of f so t ) off 

set (new_dd_area) ; 

declare ( 1 ef t_savo, answr ) (35) offset (data_sc»); 

declare (off_hdr,al 1 oc_J enrt^, qs i zo,qp1 ace, lev~l,c 

urn, nn, expo) fixed bin(17); 

declare ( s tem, numho r ) (35) fixed hm(35); 

declare new_dd_aron ama (aroa_sizo) bas<H (new_dH 

_pt r ) ; . , , . 

declare hack (35) label ( too_of_t ree, ce i l_rr»cM r , r I 

oor recur) ; 

declare now_q_aron area (area_size) ba-^H (n*w_q_p 

declare (v/d i r, i nput_pl ace) c h ar(lGS); 
declare err code fixed bind 7); 



tr) ; 



allocate dsn^ar.^s set(nev/_pt r) ; 
cal 1 | -'cs_$fs_search_sot_wdi r(addr(wdi r), j j j ) ; 
cal 1 hcs_$nako_sog(wdi r,data_type| I "_~S_new^da ta_ 
typel !"_GS_new", 1011 b, new_dr!_ptr, er r_code) ; 
if err_code>0 then do; 

call ioa_("Frror has occurec' in allocating new 
segment for data type "*Ua.File error code= "So.", 

data_type, or r_co^e) ; 
call ioa_("Uhen you wish to continue, type any 

thing and hit return."); . 

cal 1 ios_$rend_ptr(addr( i npu t_pl ace) , 1, j j j ) ; 

end ; 

call hcs_$nake_se^(\vdi r,data_typr| | M _convers i on_qu 

art", c'ata_type | | "_conversi on_quar t", ] Cllb, 
new_q_ptr, err_code) ; 
if err_code>0 then do; 

call ioa_("rrror has occured in allocating new 

segment for conversion quart."); . 

call ioa_( M nata type is "i+a. File error co^p i 

s "ko .",data_type, er r_code) ; 

call ioa_("Whon you wis u to continue, type any 

thing and hit return."); . 

cal 1 i os_$ r^ad_ptr(adHr( i npu t_pl ace) , 1, j j j ) ; 

end ; 

type_ptr=addrel ( dd nt r, -'dpt r-> f i rst_of f ) ; 

nev/_hd r =ad d re 1 ( ne\;_dd_p t r , n»v/_dH_pt r-> f i rs t_of r ) ; 

a 1 1 oc_l ength=num_on t r i es ; 

qsize=2*alloc 1 orgth+ 102-'j + 2 5 : 
csize = diviHo(qsize, 1T2^,17, r)*102ii; 

call nrea_(qs ize, new_q_pt r) ; 

allocate quart sr t ( quart_pt r ) in (new_q_a r^a ) ; 

pent (1 ) , pent(2) =nul 1 ; 

cent( 1) =da ta_type; 

cent(2)=data_type| |"_ns_n"w"; 

return r»tr=nunrf otr: 
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ca 1 1 hcs_$nakc_pt r( "", Hsm_nar^, r's^na-ie, xf^r, orr^c 
ode) ; 

if err__code>0 then do; 

call ion_("l llo^al call t~ tr^r restructure -D 
3M for old version of data type '|on S not exist."); 

cal 1 C.3_e rrorScr (9 / ,l T" / dsn.nai!;, nul 1 ) ; 
end; 
ca 1 1 cu_$ptr_ca 1 1 (xfr r, new_ptr) ; 



new_t ree: nunber ( 1 ) =a 1 loc_l on^t h ; 

next=succnsso r_c h a 1 n_H o a '' ; 

back( 1 ) =tnn_of_t r^e; 

q p 1 a c r = 1 ; 

1 e v e 1 = 1 ; 

^o to op tin; 



op tin: /*procedure ( nu'ibor, 5 ten) returns answer*/ 
if nunber ( 1 eve 1 ) =0 t''er <'o; 
answe r(level)=nullo; 
".n to hack ( 1 eve 1 ) ; 

e n ri ; 



ffset) 



1 lo; 



if numberdevel ) =1 then <-'o; 

allocate item in (now_dd_area) set ( nev.'_? ten_o 

n ew_ i t e n_p f f s e t -> f 1 a *: = ] ; 

1 as t_new_i tem_of f set- > sure =nev_i te^_o f f s^t ; 

1 a s t_n ev.'_ i t e-i_o f f s e t -n ev_ i t en_o f <"s ^ t ; 

answer (level ) = n e >: t ; 

n ew__ i t en_o ffset->lr>tr,n oy_ i t en_o ffset->rotr=nu 



nrvv_i ten_of r r;e t->rnfno = sten(]r<vel ); 
tent (qpl ac^, 1 ) =nr>: t-> ref no; 
tent( qplacr> / 2) =nev/_i ten_of f set-> refno; 
qploce=qplace+l; 

if qplace = l t^nn nov_hd r->s , .ier.r>ss r, r_c^a i n_hr?H 
=new_i tem_of f set ; 

tenp_of f set=noxt->suco; 
n e x t = t enp_o ffset; 
r.o to back( 1 evel ) ; 
end ; 



1 evel =1 evel +1 ; 

number (1 evel ) =divi r'e (nunber ( 1 evel -1) + 1, ? , 1 7, 0) ; 
f 1 oater=di vi de(nunber( 1 evel -1 ) + 1, ?, ] 7, fi) ; 
if f loater>f loat(nunher( level ), 1 7) then numberClev 
el)=number(level)+l; 

oxpo=max_depth-l evel ; 
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CUiTP 



C!C 



nn = l to expo; 
cum=cum*2 ; 



cc i i 



f 1 oor 
fset) 



one; ; 

■5 tem\ 1 eve 1 ) =s tr>n( 1 evel -I) -cir; 

back( level ) =cei l_rncur; 

CO to op tin-.; 
recur: 1 of t_save( 1 evel ) =ansv.^r( 1 ovr 1 ) ; 

answer ( 1 evel -1 ) =next; 

temp_of f set=next->suec; 

n e x t = t em p_o f f s e t ; 

number ( 1 evel ) =di vi rte (nunbe r ( 1 ev<-l -1 ) + 1/ ?- , 1 7, ) ; 

pxpo=max_l en«:tb-l evel ; 

cun=l; 

do nn=l to expo; 
cum=cum*2 ; 

end; 

s tem( 1 evel ) =s tom( 1 rv-1 -1 ) + cuti; 

bock ( 1 evel ) =f 1 oor_recu r; 

^o to opt in; 
_recur: allocate item in ( nrv;__dd_a rra) set ( new_i t^ri_of 



new_ i 
new_i 
new_i 
new_i 
last_ 
last_ 
tent( 
tent( 
qpl ac 
i f QP 

_i tem_of f set; 

level 
£0 to 

top_of_tree: la 
new_h 
new__h 
new__h 
new_h 
retur 
end ; 



tem_of f set-) f 1 o.n; = l; 

tem_of f set-> 1 pt r=l ef t_sov"( 1 evel ) ; 

tem_of f set->rntr s arswer ( 1 evr 1 ) ; 

tem_of f se t->refno=sten(level-l); 

new_i tem_of f set-> suco=ne\7_i t<">n_of f set ; 

new_i tom_of f se t =new_i tem_o^ r s^t ; 

qpl ace, ] ) =ans\v: r ( 1 eve 1 -] )->refno; 

qpl oce, 2) =nev;_i ten_of f se t->refno; 

e=qpl ace+ ] ; 

lace = l then nrw_hdr->successor_c^a i n_hrad=npv7 

=1 evel -] ; 

back ( 1 evel ) ; 
s t_nev/_i tem_of f s^ t=nu 11^; 
dr-> f i rs t_entry=ansv/er( 1) ; 
dr->max_l enpt^=nax_l er" t u ; 
dr-)num_entr i es =nun_on t r i rs; 
dr-> num_f ree_c^l 1 s=0 ; 
n; 
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APPENDIX G 

THE ERROR HANDLER 



The error handler, GS error, is called via one of six 
entries, each of the basic form: 

call GS_error$entry (error_number , one_character_error_ 

code, argl, arg2) 

The error number is printed out and also refers to the line 
in the file of error messages (GS_err_messages) which is to 
be printed out (e.g., error 51 prints out the 51st line). 
The one character code is the internal opcode to indicate to 
the user what operation was in progress. argl and arg2 
depend upon the entry: 

p, pr: argl, arg2 are pointers 

c, cr: argl is character, arg2 is a pointer 

cc, ccr : argl, arg2 are character 

Null pointers are not printed out; i.e., their absence indi- 
cates they were null. 

If one of the entries ending in "r" is used, the user is 
given the option to return from GS_error. The action taken 
then depends solely upon the invoker of GS_error. In any 
case, the user is given the options of "quit" and transfer 
to a procedure. This is done via the request: 

"Type procedure name, or quit...." or with return allowed 
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"Type procedure name, return, or quit...." 

The procedures most frequently invoked will be db and 
gsdb (see Appendix H) . Two typical error cases are given: 

call GS__error$p(121, "U", lptr, rptr) 
gives 

GS : Error 121 Internal Opcode U 

Pointer 1: 161 1 232 Pointer 2: 161 1 420 

Input quarts (pointers 1 § 2) disagree on choice 

of RSM. Type procedure name or quit.... 

call GS_error$ccr(221, "G", ent , cent(jj)) 
gives 

GS : Error 221 Internal Opcode G 

Name 1: address Name 2: address 
Discrepancy between ent (name 1) and cent (name 2) 
Return yields null result. 
Type procedure name, return, or quit.... 

One final note: typing "quit" causes signalling of the 
condition "GOLD_STAR" , so if the user should desire further 
processing of error conditions, he need only claim this con- 
dition. When a procedure name is typed, and that procedure 
returned from, GS_error reissues the request for a procedure 
name or quit (or return, if called for). 
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APPENDIX H 
GOLD STAR DEBUG (gsdb) 

The utility program gsdb is used to provide a tool with 
which to debug programs written for GOLD STAR. It may be 
invoked as a command, or as a subroutine, and Will dump to 
the console four types of items: equivalence vectors, 
quarts, RSM argument structures, and DSM argument structures. 
The latter two are produced by the manager for the RSM* s and 
DSM's and are useful to examine when a bug occurs within an 

RSM or DSM. 

From command le^el, the user types "gsdb". The program 
responds with "ASK!". All requests are of the form: 

K seg | offset 

X can be e, q, r, a, or •. The first four correspond to 
equivalence vector, quart, RSM array, and DSM array; period 
indicates quit (see Appendix E for these structures). 

When invoked as a subroutine, it is done on a per 
request basis; i.e., it is called gsdb$X (ptr) where X is 

as above. 

The quit button can be hit to interrupt unwanted output; 
the command "pi" will resume gsdb at the request point. 
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APPENDIX I 

SOME SIMPLE QUART EXAMPLES 

This appendix is intended to give the reader a few 
examples of each of the basic operations as performed on 
quarts . 



(1) 



(2) 



a 

1 



b 



c 




a 


b 


c 


3 




7 


8 


9 


6 


union 


10 


11 


12 


9 




13 


14 


IS 



union 



b 



_ 






1 


o 
L 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


a 


b 


c 


1 


2 


5 


4 


5 


6 



a b c 
1 2 3 

(3) 4 5 o 



b c a «-note the a b c 

sort 
2 3 1 12 3 



o 7 8 9 9 7 8 

10 11 12 12 10 11 

(See also sort examples to clarify -- the second quart is 
sorted before union is done to the order a-b-c.) 



(4) 



a 

1 

4 



j 



a b 

7 8 



c 
9 



a b 

7 8 



intersect 
6 10 11 i: 



o 



13 14 15 



c 
9 



- 2 40 ■ 



■sect 



.10 i J i. : 



! ) 



erencc 



8 

10 II 
13 11 



f 7 



erencc 



4 5 



1 



v.; \ 



a n 



d e 



i ! c o ci 



b 


c 


J 


e 


- 


3 


- 


S 


? 


3 




10 


5 


6 


7 


8 


5 


() 


Q 


10 



.1 11 c 



a o 



8 

S 
10 
10 
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abc k££ k i £ 

12 3 sort 100 101 102 2 13 

(11) 456 ( with res P ect t0 ) = 546 
7 8 9 8 7 9 

abc £ b a fL k £ 

12 3 100 101 102 3 2 1 

(12) 4 5 6 sort (w.r.t.) = 6 5 4 
7 8 9 9 8 7 

abc £ b £ £ k £ 

(13) 12 3 successor 7 8 9 = 10 11 12 
4 5 6 

(14) 7 8 9 successor abc a b c 
10 11 12 3 17 = 4 5 6 

(15) successor abc a b c 

10 11 15 

(16) successor abc a b £ 

111 = 123 

Note: The following operations will automatically sort the 
second argument with respect to the first in order to per- 
form the operation (see example 3): union, intersect, 
difference, successor relation. 

(17) a b c 

get ent 1 2 3 = (3) a b c (equivalence vector) 
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(18) a b c 

1 2 3 modify cnt (3) x y 



x v z 
1 2 3 



(19) a b c x b c 

12 5 modify ent (3) x § 5 = 1 2 3 



(20) a b c 

1 2 5 clear cnt 



a b £ 

1 2 5 where all 

PENT's = null 



(21) 



1 7 



:3) 



a 
1 

1 



a D 



14 15 



5 project (3) x " " z 

4 
5 
j project (_ j> J i] 

project ( 3 ) x $ " " 



1 ! 



a 


X 


I 


1 


~> 


1 


4 


5 


4 


9 


7 


10 


10 


10 


15 



X 


z 


1 


3 


1 


4 


1 


5 


a 




1 




X 


b 


1 


2 


1 


3 


1 


4 



composition using 
equivalence vectors 



(24) null vector ptr 
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a b 
1 1 
9 10 



1 
10 



(25) ( 6 ) in m v p q J', 



in £ £ x ^_ 
13 12 1 

5 6 4 5 4 



(2b) ( 6 ) mm ^ m p q 



m 
1 



E 1 
2 1 



(2 7) (b) f, w i", f, t\ w 



c 



a w _ 
1 1 3 



(2 8) (6) m n i '(, p n 



m n £_ 

1 1 3 

10 10 8 

15 15 11 



* E 

1 2 

9 7 

10 10 



Other operations do not lend themselves to simple quart 
us age . 
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